NET Api - Async Await Support

[psulek]

If i search correctly SOSS .NET provider (4.5) does not support async/await pattern yet?
I mean NamedCacheAPI nor DotNetAPI does not provide methods like:

async NamedCache.RetrieveAsync(string id, bool acquireLock): Task<Object>;

to be able to call it:

var obj = await cache.RetrieveAsync('myid', true);

I find only (but in DotNetAPI):

IAsyncResult DataAccessor.BeginRead(...)

Which can be wrapped by myself into Task<> but again, this is not solution for us because we using NamedCacheAPI.

Any ETA when you add async/await support for NET 4.5 client libraries?

 

[admin]

Update: As of November 2018, the new async-capable API mentioned in this thread is available in beta on nuget.org [nuget link]. The new library supports the locking operations discussed here by providing methods such as ReadExclusiveAsync.

Original Response:

Yes, async/await support is under active development--we've have a number of requests for it and are working to address the demand. I don't have a firm delivery date yet, however (the feature is part of a larger API refresh that we're targeting to put out this year in the late summer).

In the meantime, if you don't need to use ScaleOut's distributed locks then you can wrap NamedCache calls in async methods. Here's a gist that does just that with extension methods on the NamedCache... it doesn't do proper async IO behind the scenes, but it'll help you structure your code to use async calls right now so that your transition to the real async methods is much easier once they're available.

 

[psulek]

Thanks again for positive info about async/await support from you.

Btw we need to use distributed locks, so question is why we cant use that code in gist?

 

[admin]

The current version of the NamedCache stores lock state internally in thread-local storage, so it's incompatible with async calls that might continue on a different thread. (It's a lot like why you can't use await inside a C# lock{} statement.) We're redesigning how our internal lock tickets are managed in the next version of our APIs.

So if you need locking then you'll need to use the synchronous calls for now.

 

[psulek]

Thanks for explanation!

 

[psulek]

So with such code:

async Task ParentProcessRequest(rq) {
   namedCache.AcquireLock(key);
   try {
      await ProcessRequest(rq);
   } finally {
      namedCache.ReleaseLock(key);
   }
}

async Task ProcessRequest(rq) {
   // some other async/await processing (write to db, etc...)
}

and later called with this:

await ParentProcessRequest(rq);

there will be problem with namedCache.ReleaseLock(key) because this can be different thread than was for AcquireLock, right?

So is there any option today to use asyc/await pattern successfully with SOSS and working distributed locks? Because if its not possible our project is forced to not use async/await pattern. Our server project will heavy use state server and we need to use async/await.

Is there any way we can 'fix' this now and wait for official support from you for async/await ?