Thanks Pavel! :) On Mon, Oct 3, 2022 at 6:50 PM Pavel Tupitsyn <[email protected]> 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 <[email protected]> > wrote: > >> Jay, >> >> Thanks for the confirmation and the heads up regarding transactions. >> >> Raymond. >> >> On Mon, Oct 3, 2022 at 12:18 AM <[email protected]> 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 <[email protected]> >>> *Sent:* Sunday, 2 October 2022 11:24 >>> *To:* user <[email protected]> >>> *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. >>> >>> >>> >>> -- >>> >>> <http://www.trimble.com/> >>> >>> *Raymond Wilson*Trimble Distinguished Engineer, Civil Construction >>> Software (CCS) >>> 11 Birmingham Drive | Christchurch, New Zealand >>> [email protected] >>> >>> >>> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >>> >>> >>> >> >> >> -- >> <http://www.trimble.com/> >> Raymond Wilson >> Trimble Distinguished Engineer, Civil Construction Software (CCS) >> 11 Birmingham Drive | Christchurch, New Zealand >> [email protected] >> >> >> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >> > -- <http://www.trimble.com/> Raymond Wilson Trimble Distinguished Engineer, Civil Construction Software (CCS) 11 Birmingham Drive | Christchurch, New Zealand [email protected] <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
