Async ISynchronization

[danspam]

I am using NHibernate.Transaction.ISynchronization to run code after the transaction has committed. It would be great if there were async version of AfterCompletion and BeforeCompletion in this interface. I can see it would be easy enough to add directly to the code but all the async methods appear to be automatically generated and I am not sure how that works.

[fredericDelaporte]

It should be done the same way async is added to the ICache interface: by telling the async generator about it. See its configuration file and the many occurrences of ICache in it. Then run the generator as explained in contributing.

[fredericDelaporte]

If done the way explained in my previous comment, it will have the drawback of being a binary breaking change. Adding members to a public interface is a breaking change in .Net, since there is no way to provide a default implementation for external implementors. They will no more be able to consume the library without code changes and recompilation.
Such a change will not be merged before we decide to start a new major version (6.0).

For avoiding doing a breaking change, something like an ISynchronizationAsync interface would have to be added instead. Then async versions of NotifyLocalSynchsBeforeTransactionCompletion and NotifyLocalSynchsAfterTransactionCompletion should be manually added to the non generated file of AdoTransaction. These versions would check each synchronization, testing if they implement ISynchronizationAsync for calling its async method, otherwise calling the sync method of ISynchronization. The async generator should then be able to do the remaining work.

[hazzik]

ISynchronizationAsync -> IAsyncSynchronization. As I understand .NET convention: Async methods have "Async" suffix, classes/interfaces/delegates have "Async" prefix.

[danspam]

So would IAsyncSynchronization need to inherit from ISynchronization so that the ITransaction interface is not changed?

[fredericDelaporte]

That is a way of doing it. It could also be required to always implement also ISynchronization when implementing IAsyncSynchronization, but that would be less straightforward than enforcing it through inheritance.

[hazzik]

@fredericDelaporte I was actually thinking about the same strategy for #1452. I'll make a PR concerning both issues.

[hazzik]

This and #1452 require a few design decisions. It seems that ISynchronization and Before/AfterTransactionCompletionProcess are very similar. (They are executed in exactly same time, have same signatures, etc). In my view, it's completely unnecessary to have 2 different things doing the same job. (Hibernate has TransactionObserver interface in addition to these 2).

I have the following proposal:

1. Make a new interface: ITransactionCompletionSynchronization: ISynchronization.
2. Obsolete ISynchronization. In 6.0 only ITransactionCompletionSynchronization will survive.
3. Make a new throw away interface ITransactionCompletionSynchronizatedExecutable: IExecutable which will have a method/property ITransactionCompletionSynchronization OnTransactionCompletion.
4. Obsolete IExecutable.BeforeTransactionCompletionProcess and IExecutable.AfterTransactionCompletionProcess and add a compatibility layer to support the new way of things.

/cc @fredericDelaporte @gliljas

[fredericDelaporte]

This sounds good.

[fredericDelaporte]

#1452 has solved the root issue: such callbacks were never called asynchronously. Now the session ActionQueue allows to register before and after completion processes which can be called asynchronously.
But the ITransaction.RegisterSynchronization method has not yet evolved for proposing an overload able of being asynchronously called.