Re: Ignite Async API call continutation behaviour
Thanks Pavel! :)
On Mon, Oct 3, 2022 at 6:50 PM Pavel Tupitsyn wrote:
> Hi Raymond,
>
> Yes, you can remove those ContinueWith() calls. Default behavior is now
> safe.
>
> On Mon, Oct 3, 2022 at 2:25 AM Raymond Wilson
> wrote:
>
>> Jay,
>>
>> Thanks for the confirmation and the heads up regarding transactions.
>>
>> Raymond.
>>
>> On Mon, Oct 3, 2022 at 12:18 AM wrote:
>>
>>> Hi Raymond,
>>>
>>>
>>>
>>> That’s what we did and it works perfectly.
>>>
>>>
>>>
>>> Please note however that async/await currently does not work inside
>>> transactions, should that concern you.
>>>
>>>
>>>
>>> Pavel wrote in Jan 2022:
>>>
>>> “
>>>
>>> > Is using async/await supported for optimistic serializable
>>> transactions (and we’re doing something wrong)
>>>
>>> > or are transactional operations currently supposed to be blocking in
>>> .NET?
>>>
>>>
>>>
>>> Short answer - yes, please use synchronous cache APIs when working with
>>> transactions.
>>>
>>>
>>>
>>> A transaction is owned by a specific thread. Transactional API calls
>>> should be done from this thread, and `Commit` should be called from this
>>> thread.
>>>
>>> When doing `await`, we most likely end up on another thread and lose
>>> transaction context.
>>>
>>>
>>>
>>> There were plans to make transactions work across multiple threads, but
>>> the ticket looks abandoned:
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-4887
>>>
>>> “
>>>
>>>
>>>
>>> Issue 4887 is currently still open as I see it.
>>>
>>>
>>>
>>> Best Regard
>>>
>>> Jay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Raymond Wilson
>>> *Sent:* Sunday, 2 October 2022 11:24
>>> *To:* user
>>> *Subject:* Ignite Async API call continutation behaviour
>>>
>>>
>>>
>>> Way back in Ignite 2.8 we ran into an issue with continuations from
>>> Ignite Async method calls that meant our code could continue to run on an
>>> Ignite striped thread pool thread, with sometimes bad results.
>>>
>>>
>>>
>>> At the time the pattern suggested was to use a .ContinueWith()
>>> continuation, like this:
>>>
>>>
>>>
>>> await _cache.PutAsync(key, value).ContinueWith(t => { },
>>> CancellationToken.None, TaskContinuationOptions.None,
>>> TaskScheduler.Default);
>>>
>>>
>>>
>>> to ensure that the continuation after the PutAsync occurred on a .Net
>>> thread pool thread. This worked with no further bad results.
>>>
>>>
>>>
>>> A little while ago we upgraded to 2.13, and I note in this link (
>>> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
>>> that the default behaviour has been changed.
>>>
>>>
>>>
>>> My reading of this is that the example above can now be changed to:
>>>
>>>
>>>
>>> await _cache.PutAsync(key, value);
>>>
>>>
>>>
>>> with the continuation occurring on a .Net threadpool thread by default.
>>> Is that correct?
>>>
>>>
>>>
>>> This will allow us to remove the (quite a few) .ContinueWith()
>>> statements which do add a layer of overhead on async calls.
>>>
>>>
>>>
>>> Thanks,
>>> Raymond.
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>
--
Re: Ignite Async API call continutation behaviour
Hi Raymond,
Yes, you can remove those ContinueWith() calls. Default behavior is now
safe.
On Mon, Oct 3, 2022 at 2:25 AM Raymond Wilson
wrote:
> Jay,
>
> Thanks for the confirmation and the heads up regarding transactions.
>
> Raymond.
>
> On Mon, Oct 3, 2022 at 12:18 AM wrote:
>
>> Hi Raymond,
>>
>>
>>
>> That’s what we did and it works perfectly.
>>
>>
>>
>> Please note however that async/await currently does not work inside
>> transactions, should that concern you.
>>
>>
>>
>> Pavel wrote in Jan 2022:
>>
>> “
>>
>> > Is using async/await supported for optimistic serializable transactions
>> (and we’re doing something wrong)
>>
>> > or are transactional operations currently supposed to be blocking in
>> .NET?
>>
>>
>>
>> Short answer - yes, please use synchronous cache APIs when working with
>> transactions.
>>
>>
>>
>> A transaction is owned by a specific thread. Transactional API calls
>> should be done from this thread, and `Commit` should be called from this
>> thread.
>>
>> When doing `await`, we most likely end up on another thread and lose
>> transaction context.
>>
>>
>>
>> There were plans to make transactions work across multiple threads, but
>> the ticket looks abandoned:
>>
>> https://issues.apache.org/jira/browse/IGNITE-4887
>>
>> “
>>
>>
>>
>> Issue 4887 is currently still open as I see it.
>>
>>
>>
>> Best Regard
>>
>> Jay
>>
>>
>>
>>
>>
>>
>>
>> *From:* Raymond Wilson
>> *Sent:* Sunday, 2 October 2022 11:24
>> *To:* user
>> *Subject:* Ignite Async API call continutation behaviour
>>
>>
>>
>> Way back in Ignite 2.8 we ran into an issue with continuations from
>> Ignite Async method calls that meant our code could continue to run on an
>> Ignite striped thread pool thread, with sometimes bad results.
>>
>>
>>
>> At the time the pattern suggested was to use a .ContinueWith()
>> continuation, like this:
>>
>>
>>
>> await _cache.PutAsync(key, value).ContinueWith(t => { },
>> CancellationToken.None, TaskContinuationOptions.None,
>> TaskScheduler.Default);
>>
>>
>>
>> to ensure that the continuation after the PutAsync occurred on a .Net
>> thread pool thread. This worked with no further bad results.
>>
>>
>>
>> A little while ago we upgraded to 2.13, and I note in this link (
>> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
>> that the default behaviour has been changed.
>>
>>
>>
>> My reading of this is that the example above can now be changed to:
>>
>>
>>
>> await _cache.PutAsync(key, value);
>>
>>
>>
>> with the continuation occurring on a .Net threadpool thread by default.
>> Is that correct?
>>
>>
>>
>> This will allow us to remove the (quite a few) .ContinueWith() statements
>> which do add a layer of overhead on async calls.
>>
>>
>>
>> Thanks,
>> Raymond.
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>
>
> --
>
>
Re: Ignite Async API call continutation behaviour
Jay,
Thanks for the confirmation and the heads up regarding transactions.
Raymond.
On Mon, Oct 3, 2022 at 12:18 AM wrote:
> Hi Raymond,
>
>
>
> That’s what we did and it works perfectly.
>
>
>
> Please note however that async/await currently does not work inside
> transactions, should that concern you.
>
>
>
> Pavel wrote in Jan 2022:
>
> “
>
> > Is using async/await supported for optimistic serializable transactions
> (and we’re doing something wrong)
>
> > or are transactional operations currently supposed to be blocking in
> .NET?
>
>
>
> Short answer - yes, please use synchronous cache APIs when working with
> transactions.
>
>
>
> A transaction is owned by a specific thread. Transactional API calls
> should be done from this thread, and `Commit` should be called from this
> thread.
>
> When doing `await`, we most likely end up on another thread and lose
> transaction context.
>
>
>
> There were plans to make transactions work across multiple threads, but
> the ticket looks abandoned:
>
> https://issues.apache.org/jira/browse/IGNITE-4887
>
> “
>
>
>
> Issue 4887 is currently still open as I see it.
>
>
>
> Best Regard
>
> Jay
>
>
>
>
>
>
>
> *From:* Raymond Wilson
> *Sent:* Sunday, 2 October 2022 11:24
> *To:* user
> *Subject:* Ignite Async API call continutation behaviour
>
>
>
> Way back in Ignite 2.8 we ran into an issue with continuations from Ignite
> Async method calls that meant our code could continue to run on an Ignite
> striped thread pool thread, with sometimes bad results.
>
>
>
> At the time the pattern suggested was to use a .ContinueWith()
> continuation, like this:
>
>
>
> await _cache.PutAsync(key, value).ContinueWith(t => { },
> CancellationToken.None, TaskContinuationOptions.None,
> TaskScheduler.Default);
>
>
>
> to ensure that the continuation after the PutAsync occurred on a .Net
> thread pool thread. This worked with no further bad results.
>
>
>
> A little while ago we upgraded to 2.13, and I note in this link (
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
> that the default behaviour has been changed.
>
>
>
> My reading of this is that the example above can now be changed to:
>
>
>
> await _cache.PutAsync(key, value);
>
>
>
> with the continuation occurring on a .Net threadpool thread by default. Is
> that correct?
>
>
>
> This will allow us to remove the (quite a few) .ContinueWith() statements
> which do add a layer of overhead on async calls.
>
>
>
> Thanks,
> Raymond.
>
>
>
> --
>
>
>
>
>
--
RE: Ignite Async API call continutation behaviour
Hi Raymond,
That’s what we did and it works perfectly.
Please note however that async/await currently does not work inside
transactions, should that concern you.
Pavel wrote in Jan 2022:
“
> Is using async/await supported for optimistic serializable transactions (and
> we’re doing something wrong)
> or are transactional operations currently supposed to be blocking in .NET?
Short answer - yes, please use synchronous cache APIs when working with
transactions.
A transaction is owned by a specific thread. Transactional API calls should be
done from this thread, and `Commit` should be called from this thread.
When doing `await`, we most likely end up on another thread and lose
transaction context.
There were plans to make transactions work across multiple threads, but the
ticket looks abandoned:
https://issues.apache.org/jira/browse/IGNITE-4887
“
Issue 4887 is currently still open as I see it.
Best Regard
Jay
From: Raymond Wilson
Sent: Sunday, 2 October 2022 11:24
To: user
Subject: Ignite Async API call continutation behaviour
Way back in Ignite 2.8 we ran into an issue with continuations from Ignite
Async method calls that meant our code could continue to run on an Ignite
striped thread pool thread, with sometimes bad results.
At the time the pattern suggested was to use a .ContinueWith() continuation,
like this:
await _cache.PutAsync(key, value).ContinueWith(t => { },
CancellationToken.None, TaskContinuationOptions.None, TaskScheduler.Default);
to ensure that the continuation after the PutAsync occurred on a .Net thread
pool thread. This worked with no further bad results.
A little while ago we upgraded to 2.13, and I note in this link
(https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations)
that the default behaviour has been changed.
My reading of this is that the example above can now be changed to:
await _cache.PutAsync(key, value);
with the continuation occurring on a .Net threadpool thread by default. Is that
correct?
This will allow us to remove the (quite a few) .ContinueWith() statements which
do add a layer of overhead on async calls.
Thanks,
Raymond.
--
raymond_wil...@trimble.com
