Migrating to NH 5.1 from NH 3.3, drastic reduction in performance when using Transactions

[Sravan Kumar]

Recently Upgraded our mission critical application  to use  NH 5.1 from NH 3.3. NH 5.1 performance is comparable to NH 3.3 when not using transactions but

it drops down dramatically when using Transactions. The degradation is happening either using NHibernate ITransaction or Transaction scopes.

Seems like whole Transaction handling has been revisited from NH 5.0. Is there is any setting that needs to be turned on to bring the performance back to normal.

Here is the session factory configuration

       

        <entry key="hibernate.connection.connection_string" value="XXXXX"/>
        <entry key="hibernate.connection.provider" value="NHibernate.Connection.DriverConnectionProvider"/>
        <entry key="dialect" value="NHibernate.Dialect.MsSql2012Dialect"/>
        <entry key="connection.driver_class" value="NHibernate.Driver.SqlClientDriver"/>
        <entry key="current_session_context_class" value="wcf_operation" />
        <entry key="show_sql" value="true"></entry>
        <entry key="command_timeout" value="12000"></entry>
        <entry key="track_session_id" value="false"></entry>

[Roman]

Try setting:

<entry key="transaction.factory_class" value="NHibernate.Transaction.AdoNetTransactionFactory"/>

[Miles Thompson]

We are in a similar situation - having just upgraded from 2.1 to 5.1.

Sravan, I'd love to hear whether the change Roman suggested - of an AdoNetTransactionFactory - worked for you in terms of performance ?

Miles

[Frédéric Delaporte]

Most of the transaction rework was about system transactions (transaction scopes). Regular transaction handling was not modified much.

Using

<entry key="transaction.factory_class" value="NHibernate.Transaction.AdoNetTransactionFactory"/>

as suggested is valid only if you do not use system transactions. This transaction factory just ignores transaction scopes.

Moreover, the system transaction handling of the default transaction factory is normally not involved when using regular transactions, so switching the transaction factory should not have much impacts on projects only using regular transactions, included on performances, while it is a bug source for other projects.

Between the two transaction factories, the main difference when only using regular transactions is the fact the system aware one (and default one) will check on many occasions whether a system transaction is ongoing or not. This can be avoided by disabling the auto-join transaction feature, and explicitly asking the session to join the system transaction when you use one. https://nhibernate.info/doc/nhibernate-reference/transactions.html#transactions-scopes

The rework on system transactions has introduced thread synchronization logic to avoid concurrency troubles occurring with distributed transactions. So far it seems to have fixed most of the issues NHibernate was having with distributed transaction scopes, so it is unlikely it will be undone.

Maybe a "non-distributed system transaction" factory could be added for those not needing to support distributed transactions, and supposing the performance loss comes from these synchronizations. But things are very tricky there, a scope can be elevated to distributed on many unexpected cases. (Using ODBC data provider, or providers from SAP products (Sybase, Hana, ...) seems to always cause all scopes to be distributed; some other data-providers will go to distributed if opening, closing, reopening a connection in the scope, while others will not; ...)

[Frédéric Delaporte]

May you also state whether you have upgraded the framework by the way or not? It seems highly probable to me you have do so, due to the old version of NHibernate on which you were, and then the performance degradation could also come from that. That would be a performance regression in reading System.Transactions.Transaction.Current. So far it is the sole hypothesis I come with for explaining why you would see also a degradation with regular transactions. But it should also happen without any transaction, if that was only this.

Moreover, so far the only reports have come from people upgrading from NHibernate versions older than 4.x, so from people which were very likely to also upgrade from an .Net Framework older than v4.x. It would be great if people having that trouble can check if running their application with the old NHibernate but on an updated Framework does not already demonstrate a performance issue.

Le vendredi 29 juin 2018 02:20:12 UTC+2, Sravan Kumar a écrit :