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>
