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 <raymond_wil...@trimble.com> wrote: > Jay, > > Thanks for the confirmation and the heads up regarding transactions. > > Raymond. > > On Mon, Oct 3, 2022 at 12:18 AM <jay.et...@gmx.de> 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 <raymond_wil...@trimble.com> >> *Sent:* Sunday, 2 October 2022 11:24 >> *To:* user <user@ignite.apache.org> >> *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 >> raymond_wil...@trimble.com >> >> >> <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 > raymond_wil...@trimble.com > > > <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >
