Another problem I discovered with this, is that if you ever abort the inner transaction with CancelAsync, you set a flag which is never cleared, not even by BeginTransactionAsync, the session object is simply unusable afterwards. Which essentially means you have to create a new session object for every transaction (and since I have to use DI, it means I have to create a new DI scope for every transaction). I suppose that's probably not an unreasonable thing to need to do, I just wish it was documented or something.
CancelAsync() is here to prevent a session from being committed. Even if changes append after the call. The idea is that multiple components could change entities, but if any component says that the session should not be saved (validation error for instance) then it should keep that state.
If people think CancelAsync() is not supposed to handle that state and instead something like ModelError/ErrorState should be used (ASP.NET MVC) then they can still use that instead of calling CancelAsync.
Alternately we could add a ResetAsync() which would reset the session, by rolling back any transation or changes, and also re-initializing the cancel flag such that the session can be used as new.
CancelAsync()is here to prevent a session from being committed. Even if changes append after the call. The idea is that multiple components could change entities, but if any component says that the session should not be saved (validation error for instance) then it should keep that state.If people think
CancelAsync()is not supposed to handle that state and instead something like ModelError/ErrorState should be used (ASP.NET MVC) then they can still use that instead of calling CancelAsync.Alternately we could add a
ResetAsync()which would reset the session, by rolling back any transation or changes, and also re-initializing thecancelflag such that the session can be used as new.@ovekaaven