async operation is not fair async

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

async operation is not fair async

Dmitriy Govorukhin
Hi Igniters,

I have a question. Why our async operation in not really async?

GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
operation completed.

This means all async operation in one thread will be executed one by one
but not in parallel. Async operation is not async.

Example for atomic cache

f1=cache.getAsync(key1);
f2=cache.getAsync(key2);

f1 always will be complete before f2.

I want to have the ability run multiple async operations in one thread.
What do you think?

Maybe we can add new cache adapter with fair async operations?
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Vladimir Ozerov
+1

This would also be helpful for transactional SQL as it would allow to hide
network latency. But there is a problem - deadlocks. We need to inform user
that this mode should be used with great care.

On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Hi Igniters,
>
> I have a question. Why our async operation in not really async?
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
> operation completed.
>
> This means all async operation in one thread will be executed one by one
> but not in parallel. Async operation is not async.
>
> Example for atomic cache
>
> f1=cache.getAsync(key1);
> f2=cache.getAsync(key2);
>
> f1 always will be complete before f2.
>
> I want to have the ability run multiple async operations in one thread.
> What do you think?
>
> Maybe we can add new cache adapter with fair async operations?
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Vladimir,

Should we create the new cache adapter or rework GridCacheAdapter?

On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]>
wrote:

> +1
>
> This would also be helpful for transactional SQL as it would allow to hide
> network latency. But there is a problem - deadlocks. We need to inform user
> that this mode should be used with great care.
>
> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Hi Igniters,
> >
> > I have a question. Why our async operation in not really async?
> >
> > GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
> > operation completed.
> >
> > This means all async operation in one thread will be executed one by one
> > but not in parallel. Async operation is not async.
> >
> > Example for atomic cache
> >
> > f1=cache.getAsync(key1);
> > f2=cache.getAsync(key2);
> >
> > f1 always will be complete before f2.
> >
> > I want to have the ability run multiple async operations in one thread.
> > What do you think?
> >
> > Maybe we can add new cache adapter with fair async operations?
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Ivan Rakov
I think, the best option from API side is to add decorating
withExplicitAsync() method.
We already have withKeepBinary, withExpiryPolicy and so on.

Best Regards,
Ivan Rakov

On 11.05.2018 18:18, Dmitriy Govorukhin wrote:

> Vladimir,
>
> Should we create the new cache adapter or rework GridCacheAdapter?
>
> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> +1
>>
>> This would also be helpful for transactional SQL as it would allow to hide
>> network latency. But there is a problem - deadlocks. We need to inform user
>> that this mode should be used with great care.
>>
>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
>> [hidden email]> wrote:
>>
>>> Hi Igniters,
>>>
>>> I have a question. Why our async operation in not really async?
>>>
>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
>>> operation completed.
>>>
>>> This means all async operation in one thread will be executed one by one
>>> but not in parallel. Async operation is not async.
>>>
>>> Example for atomic cache
>>>
>>> f1=cache.getAsync(key1);
>>> f2=cache.getAsync(key2);
>>>
>>> f1 always will be complete before f2.
>>>
>>> I want to have the ability run multiple async operations in one thread.
>>> What do you think?
>>>
>>> Maybe we can add new cache adapter with fair async operations?
>>>

Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Ivan,

My suggestion "withFairAsync()". What do you think?

On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> wrote:

> I think, the best option from API side is to add decorating
> withExplicitAsync() method.
> We already have withKeepBinary, withExpiryPolicy and so on.
>
> Best Regards,
> Ivan Rakov
>
>
> On 11.05.2018 18:18, Dmitriy Govorukhin wrote:
>
>> Vladimir,
>>
>> Should we create the new cache adapter or rework GridCacheAdapter?
>>
>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]>
>> wrote:
>>
>> +1
>>>
>>> This would also be helpful for transactional SQL as it would allow to
>>> hide
>>> network latency. But there is a problem - deadlocks. We need to inform
>>> user
>>> that this mode should be used with great care.
>>>
>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
>>> [hidden email]> wrote:
>>>
>>> Hi Igniters,
>>>>
>>>> I have a question. Why our async operation in not really async?
>>>>
>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
>>>> operation completed.
>>>>
>>>> This means all async operation in one thread will be executed one by one
>>>> but not in parallel. Async operation is not async.
>>>>
>>>> Example for atomic cache
>>>>
>>>> f1=cache.getAsync(key1);
>>>> f2=cache.getAsync(key2);
>>>>
>>>> f1 always will be complete before f2.
>>>>
>>>> I want to have the ability run multiple async operations in one thread.
>>>> What do you think?
>>>>
>>>> Maybe we can add new cache adapter with fair async operations?
>>>>
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Ivan Rakov
Agree. "fair" is more descriptive.

Best Regards,
Ivan Rakov

On 11.05.2018 18:30, Dmitriy Govorukhin wrote:

> Ivan,
>
> My suggestion "withFairAsync()". What do you think?
>
> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> wrote:
>
>> I think, the best option from API side is to add decorating
>> withExplicitAsync() method.
>> We already have withKeepBinary, withExpiryPolicy and so on.
>>
>> Best Regards,
>> Ivan Rakov
>>
>>
>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote:
>>
>>> Vladimir,
>>>
>>> Should we create the new cache adapter or rework GridCacheAdapter?
>>>
>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]>
>>> wrote:
>>>
>>> +1
>>>> This would also be helpful for transactional SQL as it would allow to
>>>> hide
>>>> network latency. But there is a problem - deadlocks. We need to inform
>>>> user
>>>> that this mode should be used with great care.
>>>>
>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
>>>> [hidden email]> wrote:
>>>>
>>>> Hi Igniters,
>>>>> I have a question. Why our async operation in not really async?
>>>>>
>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
>>>>> operation completed.
>>>>>
>>>>> This means all async operation in one thread will be executed one by one
>>>>> but not in parallel. Async operation is not async.
>>>>>
>>>>> Example for atomic cache
>>>>>
>>>>> f1=cache.getAsync(key1);
>>>>> f2=cache.getAsync(key2);
>>>>>
>>>>> f1 always will be complete before f2.
>>>>>
>>>>> I want to have the ability run multiple async operations in one thread.
>>>>> What do you think?
>>>>>
>>>>> Maybe we can add new cache adapter with fair async operations?
>>>>>
>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Igniters,

I created the issue. IGNITE-8475
<https://issues.apache.org/jira/browse/IGNITE-8475>

Any comments are welcome.

On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]> wrote:

> Agree. "fair" is more descriptive.
>
> Best Regards,
> Ivan Rakov
>
>
> On 11.05.2018 18:30, Dmitriy Govorukhin wrote:
>
>> Ivan,
>>
>> My suggestion "withFairAsync()". What do you think?
>>
>> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]>
>> wrote:
>>
>> I think, the best option from API side is to add decorating
>>> withExplicitAsync() method.
>>> We already have withKeepBinary, withExpiryPolicy and so on.
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>>
>>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote:
>>>
>>> Vladimir,
>>>>
>>>> Should we create the new cache adapter or rework GridCacheAdapter?
>>>>
>>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]>
>>>> wrote:
>>>>
>>>> +1
>>>>
>>>>> This would also be helpful for transactional SQL as it would allow to
>>>>> hide
>>>>> network latency. But there is a problem - deadlocks. We need to inform
>>>>> user
>>>>> that this mode should be used with great care.
>>>>>
>>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Hi Igniters,
>>>>>
>>>>>> I have a question. Why our async operation in not really async?
>>>>>>
>>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async
>>>>>> operation completed.
>>>>>>
>>>>>> This means all async operation in one thread will be executed one by
>>>>>> one
>>>>>> but not in parallel. Async operation is not async.
>>>>>>
>>>>>> Example for atomic cache
>>>>>>
>>>>>> f1=cache.getAsync(key1);
>>>>>> f2=cache.getAsync(key2);
>>>>>>
>>>>>> f1 always will be complete before f2.
>>>>>>
>>>>>> I want to have the ability run multiple async operations in one
>>>>>> thread.
>>>>>> What do you think?
>>>>>>
>>>>>> Maybe we can add new cache adapter with fair async operations?
>>>>>>
>>>>>>
>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
Guys,

I am not sure I like this approach, especially for this code:

f1=cache.getAsync(key1);
f2=cache.getAsync(key2);

You cannot complete f2 before f1. If you do, the code is unusable and it is
impossible to predict anything. If you need to get 2 elements
asynchronously, use getAllAsync() instead.

Let's not introduce such usability issues into our API and stop trying to
fix what's not broken. I propose to close the ticket as "Won't Fix".

D.

On Fri, May 11, 2018 at 6:14 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Igniters,
>
> I created the issue. IGNITE-8475
> <https://issues.apache.org/jira/browse/IGNITE-8475>
>
> Any comments are welcome.
>
> On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]> wrote:
>
> > Agree. "fair" is more descriptive.
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 11.05.2018 18:30, Dmitriy Govorukhin wrote:
> >
> >> Ivan,
> >>
> >> My suggestion "withFairAsync()". What do you think?
> >>
> >> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]>
> >> wrote:
> >>
> >> I think, the best option from API side is to add decorating
> >>> withExplicitAsync() method.
> >>> We already have withKeepBinary, withExpiryPolicy and so on.
> >>>
> >>> Best Regards,
> >>> Ivan Rakov
> >>>
> >>>
> >>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote:
> >>>
> >>> Vladimir,
> >>>>
> >>>> Should we create the new cache adapter or rework GridCacheAdapter?
> >>>>
> >>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <
> [hidden email]>
> >>>> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>>> This would also be helpful for transactional SQL as it would allow to
> >>>>> hide
> >>>>> network latency. But there is a problem - deadlocks. We need to
> inform
> >>>>> user
> >>>>> that this mode should be used with great care.
> >>>>>
> >>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
> >>>>> [hidden email]> wrote:
> >>>>>
> >>>>> Hi Igniters,
> >>>>>
> >>>>>> I have a question. Why our async operation in not really async?
> >>>>>>
> >>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last
> async
> >>>>>> operation completed.
> >>>>>>
> >>>>>> This means all async operation in one thread will be executed one by
> >>>>>> one
> >>>>>> but not in parallel. Async operation is not async.
> >>>>>>
> >>>>>> Example for atomic cache
> >>>>>>
> >>>>>> f1=cache.getAsync(key1);
> >>>>>> f2=cache.getAsync(key2);
> >>>>>>
> >>>>>> f1 always will be complete before f2.
> >>>>>>
> >>>>>> I want to have the ability run multiple async operations in one
> >>>>>> thread.
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Maybe we can add new cache adapter with fair async operations?
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Pavlov
IMO you can complete async operations one before another if these
operations are related to independent data.

It is strange why Ignite users are not confused by current API. So I
support Dmitriy's G. suggestion.

пт, 11 мая 2018 г. в 20:24, Dmitriy Setrakyan <[hidden email]>:

> Guys,
>
> I am not sure I like this approach, especially for this code:
>
> f1=cache.getAsync(key1);
> f2=cache.getAsync(key2);
>
> You cannot complete f2 before f1. If you do, the code is unusable and it is
> impossible to predict anything. If you need to get 2 elements
> asynchronously, use getAllAsync() instead.
>
> Let's not introduce such usability issues into our API and stop trying to
> fix what's not broken. I propose to close the ticket as "Won't Fix".
>
> D.
>
> On Fri, May 11, 2018 at 6:14 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Igniters,
> >
> > I created the issue. IGNITE-8475
> > <https://issues.apache.org/jira/browse/IGNITE-8475>
> >
> > Any comments are welcome.
> >
> > On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]>
> wrote:
> >
> > > Agree. "fair" is more descriptive.
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > >
> > > On 11.05.2018 18:30, Dmitriy Govorukhin wrote:
> > >
> > >> Ivan,
> > >>
> > >> My suggestion "withFairAsync()". What do you think?
> > >>
> > >> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]>
> > >> wrote:
> > >>
> > >> I think, the best option from API side is to add decorating
> > >>> withExplicitAsync() method.
> > >>> We already have withKeepBinary, withExpiryPolicy and so on.
> > >>>
> > >>> Best Regards,
> > >>> Ivan Rakov
> > >>>
> > >>>
> > >>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote:
> > >>>
> > >>> Vladimir,
> > >>>>
> > >>>> Should we create the new cache adapter or rework GridCacheAdapter?
> > >>>>
> > >>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <
> > [hidden email]>
> > >>>> wrote:
> > >>>>
> > >>>> +1
> > >>>>
> > >>>>> This would also be helpful for transactional SQL as it would allow
> to
> > >>>>> hide
> > >>>>> network latency. But there is a problem - deadlocks. We need to
> > inform
> > >>>>> user
> > >>>>> that this mode should be used with great care.
> > >>>>>
> > >>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin <
> > >>>>> [hidden email]> wrote:
> > >>>>>
> > >>>>> Hi Igniters,
> > >>>>>
> > >>>>>> I have a question. Why our async operation in not really async?
> > >>>>>>
> > >>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last
> > async
> > >>>>>> operation completed.
> > >>>>>>
> > >>>>>> This means all async operation in one thread will be executed one
> by
> > >>>>>> one
> > >>>>>> but not in parallel. Async operation is not async.
> > >>>>>>
> > >>>>>> Example for atomic cache
> > >>>>>>
> > >>>>>> f1=cache.getAsync(key1);
> > >>>>>> f2=cache.getAsync(key2);
> > >>>>>>
> > >>>>>> f1 always will be complete before f2.
> > >>>>>>
> > >>>>>> I want to have the ability run multiple async operations in one
> > >>>>>> thread.
> > >>>>>> What do you think?
> > >>>>>>
> > >>>>>> Maybe we can add new cache adapter with fair async operations?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov <[hidden email]>
wrote:

> IMO you can complete async operations one before another if these
> operations are related to independent data.
>
> It is strange why Ignite users are not confused by current API. So I
> support Dmitriy's G. suggestion.
>

Again, this is a solution looking for a problem. Nobody complains about
this, so there really isn't any issue. There are so many other tasks we
could focus on. Let's not fix what's not broken.

D.
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Dmitriy S,

Why method named as "async" but does not work as async? This is misleading.

getAllAsync() is a special case. Not always you can use getAllAsync() instead
of multiple getAsync().
In this topic, I wanna discuss problem not only for the GET operation but
also all async operation behavior in the one thread.

In compute grid we can run multiple async compute operation in the one
thread, so why we can not do this for cache?


On Fri, May 11, 2018 at 8:33 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov <[hidden email]>
> wrote:
>
> > IMO you can complete async operations one before another if these
> > operations are related to independent data.
> >
> > It is strange why Ignite users are not confused by current API. So I
> > support Dmitriy's G. suggestion.
> >
>
> Again, this is a solution looking for a problem. Nobody complains about
> this, so there really isn't any issue. There are so many other tasks we
> could focus on. Let's not fix what's not broken.
>
> D.
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Dmitriy S,
>
> Why method named as "async" but does not work as async? This is misleading.
>
> getAllAsync() is a special case. Not always you can use getAllAsync()
> instead
> of multiple getAsync().
> In this topic, I wanna discuss problem not only for the GET operation but
> also all async operation behavior in the one thread.
>
> In compute grid we can run multiple async compute operation in the one
> thread, so why we can not do this for cache?


Because it will break a lot of existing code and create bugs we cannot even
predict at this point. I am not sure why has this become a problem. Is it
preventing us from accomplishing some other task? If not, then I propose to
drop it.

D.
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Dmitriy S,

It is not broke existing code, because for use this ability you must use
decorator "withFairSycn()".

What about the argument of Vladimir?

On Fri, May 11, 2018 at 8:41 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Dmitriy S,
> >
> > Why method named as "async" but does not work as async? This is
> misleading.
> >
> > getAllAsync() is a special case. Not always you can use getAllAsync()
> > instead
> > of multiple getAsync().
> > In this topic, I wanna discuss problem not only for the GET operation but
> > also all async operation behavior in the one thread.
> >
> > In compute grid we can run multiple async compute operation in the one
> > thread, so why we can not do this for cache?
>
>
> Because it will break a lot of existing code and create bugs we cannot even
> predict at this point. I am not sure why has this become a problem. Is it
> preventing us from accomplishing some other task? If not, then I propose to
> drop it.
>
> D.
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Dmitriy S,
>
> It is not broke existing code, because for use this ability you must use
> decorator "withFairSycn()".
>
> What about the argument of Vladimir?
>

Here is Vladimir's quote:


*This would also be helpful for transactional SQL as it would allow to
hide**network
latency. But there is a problem - deadlocks. We need to inform user*
*that this mode should be used with great care. *


I would rather not change anything instead of increasing the probability of
deadlocks. This was the main reason for the current behavior to begin with.

In my view, if something is needed for the transactional SQL, please add it
internally. Let's not corrupt the public API by adding dangerous methods.

D.
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
Dmitriy S,

If it will be in the internal package, and only for internal usage, are you
agree with changes?

пт, 11 мая 2018 г., 21:12 Dmitriy Setrakyan <[hidden email]>:

> On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Dmitriy S,
> >
> > It is not broke existing code, because for use this ability you must use
> > decorator "withFairSycn()".
> >
> > What about the argument of Vladimir?
> >
>
> Here is Vladimir's quote:
>
>
> *This would also be helpful for transactional SQL as it would allow to
> hide**network
> latency. But there is a problem - deadlocks. We need to inform user*
> *that this mode should be used with great care. *
>
>
> I would rather not change anything instead of increasing the probability of
> deadlocks. This was the main reason for the current behavior to begin with.
>
> In my view, if something is needed for the transactional SQL, please add it
> internally. Let's not corrupt the public API by adding dangerous methods.
>
> D.
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Dmitriy S,
>
> If it will be in the internal package, and only for internal usage, are you
> agree with changes?
>

Yes, but please be careful not to create deadlocks for ourselves.

Can you please close the ticket?

D.
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Dmitriy Govorukhin
I will edit IGNITE-8475, and remove all part that belong to the public api.
Is it acceptable for you?

пт, 11 мая 2018 г., 21:29 Dmitriy Setrakyan <[hidden email]>:

> On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Dmitriy S,
> >
> > If it will be in the internal package, and only for internal usage, are
> you
> > agree with changes?
> >
>
> Yes, but please be careful not to create deadlocks for ourselves.
>
> Can you please close the ticket?
>
> D.
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin <
[hidden email]> wrote:

> I will edit IGNITE-8475, and remove all part that belong to the public api.
> Is it acceptable for you?
>

Everything is acceptable, as long as the public API is safe :)
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

Vladimir Ozerov
Guys,

To build a great product we should be open minded and look to the future,
not to the past.

Dima raised very valid point - why async is not async? Current programming
culture and demanding performance requirements pushes users towards
reactive-style programming. I do not want my thread to ever be blocked.
Instead, I want to send a number of concurrent commands and optionally
subscribe to final result. So trully async API makes total sense to me.

But personally, my primary interest in this area is SQL. Oracle is
preparing new async driver. ADBA - async database access. It was presented
on recent JavaOne [1]. It is under active development right now - juse
weave through the mailing list [2]. Some prototypes are already there [3].
PostgreSQL community even started adopted it [4]!

I am not pushing for immediate actions, but at least we should understand
which way the wind is blowing. As a mid-term goals I would propose to
finally remove thread ID from our PESSIMISTIC transactions to allow for
suspend/resume in different threads. And as a next step I would think on
adopting async cache and SQL APIs.

Vladimir.

[1]
http://www.oracle.com/technetwork/database/application-development/jdbc/con1491-3961036.pdf
[2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/
[3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ
[4] https://github.com/pgjdbc/pgjdbc/issues/978

On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > I will edit IGNITE-8475, and remove all part that belong to the public
> api.
> > Is it acceptable for you?
> >
>
> Everything is acceptable, as long as the public API is safe :)
>
Reply | Threaded
Open this post in threaded view
|

Re: async operation is not fair async

dsetrakyan
Vladimir,

In general I agree, but I do get greatly *close-minded* (pun intended)
whenever users' code that worked for the past several years all of a sudden
gets deadlocked after an upgrade. Making this feature optional is even
worse and more confusing. In this case the best action is no action at all.

BTW, would be interesting to find out how Oracle async driver behaves in
this case.

D.





On Fri, May 11, 2018 at 8:29 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Guys,
>
> To build a great product we should be open minded and look to the future,
> not to the past.
>
> Dima raised very valid point - why async is not async? Current programming
> culture and demanding performance requirements pushes users towards
> reactive-style programming. I do not want my thread to ever be blocked.
> Instead, I want to send a number of concurrent commands and optionally
> subscribe to final result. So trully async API makes total sense to me.
>
> But personally, my primary interest in this area is SQL. Oracle is
> preparing new async driver. ADBA - async database access. It was presented
> on recent JavaOne [1]. It is under active development right now - juse
> weave through the mailing list [2]. Some prototypes are already there [3].
> PostgreSQL community even started adopted it [4]!
>
> I am not pushing for immediate actions, but at least we should understand
> which way the wind is blowing. As a mid-term goals I would propose to
> finally remove thread ID from our PESSIMISTIC transactions to allow for
> suspend/resume in different threads. And as a next step I would think on
> adopting async cache and SQL APIs.
>
> Vladimir.
>
> [1]
> http://www.oracle.com/technetwork/database/application-development/jdbc/
> con1491-3961036.pdf
> [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/
> [3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ
> [4] https://github.com/pgjdbc/pgjdbc/issues/978
>
> On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin <
> > [hidden email]> wrote:
> >
> > > I will edit IGNITE-8475, and remove all part that belong to the public
> > api.
> > > Is it acceptable for you?
> > >
> >
> > Everything is acceptable, as long as the public API is safe :)
> >
>
12