I tried one and the same service call with and without NHibernate BeginTransaction. Watched the behavior with NHProf, the collection pool with perfmon and SQL Server profiler and didn’t see any indications of leaking connections in either case. The only difference was that in the first case (with BeginTransaction) there were two nested transactions:

Case #1 with BeginTransaction:
**************************************– statement #1enlisted session in distributed transaction with isolation level: ReadCommitted– statement #2begin transaction with isolation level: ReadCommitted– statement #3select userevent0_.Id               as Id1_0_,…– statement #4SELECT usereventn0_.UserEvent_id   as UserEvent1_0_,…– statement #5commit transaction– statement #6commit transaction
Case #2 without BeginTransaction
**************************************– statement #1enlisted session in distributed transaction with isolation level: ReadCommitted– statement #2select userevent0_.Id as Id1_0_,…– statement #3SELECT usereventn0_.UserEvent_id as UserEvent1_0_,…– statement #4commit transaction

using (var scope = new TransactionScope(TransactionScopeOption.Required))
{
using (var session = sessionFactory.OpenSession())
{
var blah = session.CreateCriteria().List();
}
}

You need add “enlist=dynamic” in Oracle connection string for Distributed transaction. Otherwise, throw exception.


using (var scope = new TransactionScope(TransactionScopeOption.Required))

{

using (var session = sessionFactory.OpenSession())

using (var transaction = session.BeginTransaction())

{

// do what you need to do with the session

transaction.Commit();

}

scope.Complete();

}


[NHibernate.TransactionException]{"Begin failed with SQL exception"}
The connection is already part of a local or distributed transaction


I cannot begin a NHibernate transaction inside a Transaction Scope.

I’m using Oracle 11G and Nhibernate 2.1.2

Any clues?

regards

Rodrigo

PD. I previously turned off Enlist on Oracle, but I also have an Oracle MembershipProvider and Logging App Blocks inserts which should be held on the same TransactionScope (So it is mandatory).

First of all thanks for the valuable info

Did you solve the WCF-Oracle 11G issue?

I have to configure WCF with transactionScope per service call against some separate nhibernate sessions, so all of them should be elisted on the same TransactionScope.

regards

Rodrigo

I’ve run into that issue as well. In order to get rid of that error, I changed the ‘Enlist’ value in my connection string to false. However, any transaction you use then becomes local. If you were to check the System.Transactions.Transaction.Current.TransactionInformation.DistributedIdentifier value with Enlist set to true (before it hits the session.BeginTransaction(), you’ll see it’s populated. Otherwise, it’s all zeroes.

As I am currently trying to configure WS-Atomic Transaction for my WCF service, using NHibernate and Oracle 11g R2, I need to get past this issue as well.

using (var scope = new TransactionScope(TransactionScopeOption.Required))

{
using (var session = sessionFactory.OpenSession())
using (var transaction = session.BeginTransaction())
{
// do what you need to do with the session
transaction.Commit();
}
scope.Complete();
}

AdoNetTransactionFactory also doesn’t work very well, based on what I see it opens calls connection pool too many times, and if I put 10 sinc threads to do some work I have \to many connections\ exception.

interesting… i reran the test with AdoNetTransactionFactory and you’re right… it doesn’t have the leaking connection problem and the connection indeed appears to enlist properly in the distributed transaction

i’d have to investigate further, but this quick test does make me think that AdoNetTransactionFactory is more suitable for dealing with Distributed Transactions than the AdoNetWithDistributedTransactionFactory

We are using our own session class that implements ISession and passes nearly all calls directly through to a local instance of NHibernate’s SessionImpl class. As it turns out, our Dispose() does a little more work than just passing through. In fact it is calling the Close() and the Disconnect() methods on the SessionImpl instance directly. Take these calls out of our custom session (so it just basically passes the call through) and I have the same leaking connection result that I expected to see!

I’ve been running some tests within our solution framework to see if we are vulnerable to this problem since our pattern for using TransactionScope is the same as your test case. The difference with our’s is that we use the AdoNetTransactionFactory. From my investigations so far, I’ve found that connections are not leaked when this class is used instead of the default AdoNetWithDistrubtedTransactionFactory. So I decided to switch to the AdoNetWithDistrubtedTransactionFactory to make sure that I could replicate your results. On the first iteration of the loop, my test ran into the following exception.

System.InvalidOperationException: Disconnect cannot be called while a transaction is in progress.

After a little investigation, I found that this is the exception NHibernate throws if ConnectionManager.Disconnect() is called while there is still an active transaction. This method is called when a session is Disposed, which in this case is happening at the end of the session using block within the TransactionScope using block. So I had to ask: why does this not happen in your code?!

using (var scope = new TransactionScope(TransactionScopeOption.Required))
{
using (var session = sessionFactory.OpenSession())
{
var blah = session.CreateCriteria().List();
} // Disconnect called here, but transaction is still active, so exception is thrown.
}

If we change the code to be as follows, then I get the same result as you (i.e. max pool size reached exception).

using (var session = sessionFactory.OpenSession())
{
using (var scope = new TransactionScope(TransactionScopeOption.Required))
{
var blah = session.CreateCriteria().List();
}
}

This code isn’t particularly useful within our solution, so we will stick to the AdoNetTransactionFactory for now, as this is working well for us. I believe this is because of what Peter has said above, the actual Ado Connection is enlisting in the transaction even if NHibernate is ignoring it. I’m just worried because the distributed transaction factory class SHOULD work for this! I’ve seen several posts from people having the same problem as I found, but so far no one has suggested a reason for it. Have you got any ideas about it? Have you come across it before?

We are using 2.1.2 and I have posted our config below (using the distributed transaction factory instead)

Thanks!

Sam

NHibernate.Connection.DriverConnectionProvider
NHibernate.Dialect.MsSql2005Dialect
NHibernate.Driver.SqlClientDriver
ReadCommitted
20
NHibernate.ByteCode.LinFu.ProxyFactoryFactory, NHibernate.ByteCode.LinFu
NHibernate.Transaction.AdoNetWithDistrubtedTransactionFactory, NHibernate

I hope I can shed some light. The project I am on uses the same pattern as your test case. Create a transaction scope, open session, execute sql. However we use ADONetTransactionfacory. Doing the same test we are not seeing connections leaking. I believe this is because the ADO connection automatically enlists in the ambient transaction. So when there is no transactionscope.commit or exception is raised the impact of the session using is to rollback transaction and close connection. In other words we are using NHibernate to create the connection, execute the sql and perform the ORM stuff and rely on transactionscope to manage the distributed transactions.

I wonder one of the issues with AdoNetWithDistributedTransactionFactory class is related to the connection automatically enlisting in the ambient transaction when the code is assuming it is managing the enlistment. I am concerned when I see this in the code

public void AfterTransaction()
{
if (IsAfterTransactionRelease)
{
AggressiveRelease();
}
else if (IsAggressiveRelease && batcher.HasOpenResources)
{
log.Info(“forcing batcher resource cleanup on transaction completion; forgot to close ScrollableResults/Enumerable?”);
batcher.CloseCommands();
AggressiveRelease();
}
else if (IsOnCloseRelease)
{
// log a message about potential connection leaks
log.Debug(
“transaction completed on session with on_close connection release mode; be sure to close the session to release ADO.Net resources!”);
}
transaction = null;
}

cheers
peter

haven’t tried it with AdoNetTransactionFactory yet, since that’s not even used by default. Even when you’re not using TransactionScope, NH will use AdoNetWithDistributedTransactionFactory

is the leaking happening with both transaction factory classes AdoNetTransactionfactory and AdoNetWithDistributedTransactionFactory

ah, i once had an issue where Disposing the session caused problems in combination with TransactionScope. But that was when the TransactionScope was created before the Session was. In that situation, i just had to close the session instead of disposing it