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
 <mailto:[email protected]> [email protected]

        
                                                

 
<https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
 

 

Reply via email to