Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> CommitAsync
 

Pages: 1
Bugs & Issues
CommitAsync
Page:1/1 

  Print all messages in this thread  
Poster Message
WayneBrantley
User



Location:
USA
Joined on:
10-Mar-2006 16:20:08
Posted:
1114 posts
# Posted on: 22-Nov-2014 03:17:44.  
I have been using your new async support all over the place, seems to work great.

Why isn't their a CommitAsync() call on a transaction object?

I can do:

Code:

entity.SaveAsync();
entity2.SaveAsync();
entity3.SaveAsync();


but not
Code:

transaction.add(entity);
transaction.add2(entity);
transaction.add3(entity);
entity.Save();
entity2.Save();
entity3.Save();
await transaction.CommitAsync();


Seems like a missing feature?
SelfServicing, .Net 4.5, Web Applications, SqlServer 2014  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8088 posts
# Posted on: 22-Nov-2014 07:15:23.  
Hi Wayne,

I think that what you ask is answered in the docs:
Quote:
Unit of Work and Async
The Unit of work classes are also async aware and have been updated with async variants of some of their methods. Using the unit of work classes hasn't changed, only the way to commit the unit of work, using CommitAsync. CommitAsync is equal to Commit, however it's an asynchronous method which can be awaited and which performs all its actions asynchronously:

- Opening the connection is asynchronous (adapter)
- Every element to execute is executed asynchronously, except stored procedure calls and callbacks.

Transaction create, commit/rollback are synchronous as there's no ADO.NET way to do these actions asynchronously. All actions taken by the unit of work are done asynchronously and the results are awaited before the next action is performed.


Synchronous code used by asynchronous methods
Saving an entity asynchronously and refetching it will do the save part (insert or update) asynchronously but will do the fetch part synchronously. This is because the fetch uses the FetchEntity method on adapter and a call to a generated method in SelfServicing, requiring more code to be ported / copied to make things async than reasonable, so we left that synchronously. Fetches of entities are single row returning queries using PK filters, so the queries should execute very quickly and the delay be minimal, so making this piece of the pipeline asynchronous wouldn't make things behave that differently, hence we left it as-is.

TransactionScope and Async
Although the API supports TransactionScope/System.Transactions, it's mandatory that the code which creates the TransactionScope and which has one or more await statements inside the TransactionScope, has a valid SynchronizationContext active on the current thread. If not, the TransactionScope will fail, because it's being disposed on another thread due to the await statement. This is a general aspect of asynchronous programming and .NET and not something we can avoid.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.