Nested/Concurrent transactions aren't supported

[Michael Craig]

Hi guys,

I'm using PostgreSQL and Npgsql but I have isolated the issue to NHibernate behaviour. Here is the sample code which breaks, during the following code, we are already inside a Session and an ambient TranscationScope, then we nest like so:

var openSession = ObjectFactory.GetInstance<ISession>();
using (var trans = new TransactionScope(TransactionScopeOption.Suppress, new TransactionOptions { Timeout = new TimeSpan(0, 5, 0) })) {
    using (var newSession = sessionFactory.OpenStatelessSession(openSession.Connection)) {
        using (var nhTrans = newSession.BeginTransaction()) {
            Stuff();
        }
    }
}

This code is operational using any NHib v4. But with any NHib Version v5+ it will throw the title exception 'Nested/Concurrent transactions aren't supported'. This is the case with any NpgSql 3+, making it likely that some behaviour of NHib changed (maybe correctly of course).

I have read the issues revolving around the configuration parameter 'transaction.use_connection_on_system_prepare` and that doesn't help in this case. I find that in all cases, newSession.Connection.Connector == openSession.Connection.Connector and the NpgSql code has always checked against Connector.InTransaction before throwing, so NHibernate must be bypassing this somehow, although I can't see any evidence of that in the source code!

Anyone got any ideas why exactly this blows up in NHib v5+ only?

Thanks,

Mike

[frederic...@free.fr]

Contributing a test case would allow to sort out if this is a NHibernate bug or not.

I personally suspect that some use of the session has been done prior to the scope suppression, causing it to acquire the connection. Since NHibernate v5, the connection is enlisted into the ambient transaction (if any) when acquired, even if its connection string auto-enlistment setting is disabled. (This can be disabled by switching the session option `AutoJoinTransaction` to false, by using the `WithOptions` method on the session factory for opening the session.)

A connection stay enlisted with a transaction until it ends, even if the connection is used inside a suppressed scope.

A session acquires its connection on the first operation requiring it, and by default releases it at the end of the transaction.

Note that Npgsql auto-enlistment behavior has also changed, being enabled by default around its 3.3 version, then re-disabled, then re-enabled in v4. See here. It has also got many system transactions related changes.

It would be safer to change your pattern for opening the session inside the suppressed scope rather than outside of it. Otherwise you can `Disconnect` and immediately `Reconnect` the session to ensure it uses a new connection.