Database connection is not closed after rollback in TransactionScope

Description

.Net Framework Version: 3.5
Database: SQL Server 2005

We have just migrated from version 1.2.1 to 2.1.2GA since we need to integrate multiple layer of components using the TransactionScope. After some testing, we find that the database connection increases continuously after every transaction rollback. At the end, all the connections in the connection pool are used up. The problem does not occur in commit case.

Here is the testing code:

After running the above case, a new connection will be used in SQL Server. The connection will not free up in SQL Server until we close our application.

Any advise for the problem? Thanks in advance.

Environment

None

Attachments

1

Activity

Show:

Frédéric Delaporte 
June 29, 2017 at 5:11 PM
(edited)

From what I can read here, it looks like the connection leaks occurs only with SQL Server 2005, while the code has actually called IDbConnection.Close on the connection.

So this case seems to be an external issue (bug) specific to SQL Server 2005, occurring in corner case circumstances in which unfortunately NHibernate falls, and fixed with SQL Server 2008.

Since SQL Server 2005 reached end of life one year ago, I think it is time to close that issue. Unless someone can provide a test case for another database. Please in such case be as explicit as possible. Reading all comments here and supplied test cases, it was not even clear to me whether being in a distributed case was required for triggering the bug, or not.

Oskar Berggren 
April 13, 2012 at 3:26 PM

I concur that trivial is probably too low priority. Setting Major.

John Thornborrow 
April 12, 2012 at 9:32 AM

Please ignore my previous comment. This turned out to be a red herring (for as yet unidentified reasons). Changing the transaction strategy does not resolve the issue(s).

John Thornborrow 
April 11, 2012 at 1:54 PM

Old issue bumped..

Today I discovered that in 3.2.0GA that using the TransactionStrategy AdoNetWithDistributedTransaction negates the necessity for using ISession.BeginTransaction().

e.g. the following test case works (i.e. changes are persisted):

using (var txs = new TransactionScope()) {
session.Save(new Thing { Id = 123 });
var thingRetrieved = session.Query<Thing>().Single(eachThing => eachThing.Id == 123);
thingRetrieved.Name = "Some Name";
tsx.Complete();
}

Travis Shepherd 
November 18, 2011 at 8:39 PM

Categorizing this as trivial seems a little... off. It seems to work fine with SQL Server Compact 4.0, SQL Server 2008R2, and Oracle 11G. SQL Server 2005 fails though.

This workaround (http://davybrion.com/blog/2010/05/avoiding-leaking-connections-with-nhibernate-and-transactionscope/) is not ideal, as it causes other issues with SQL Server Compact (http://stackoverflow.com/questions/8127735/how-can-i-use-transactionscope-with-sql-compact-4-0-and-nhibernate).

I'm going to have to work around the work-around this by detecting SQL Server Compact at runtime, and avoiding creating an NHibernate transaction.

External Issue

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

Who's Looking?

Open Who's Looking?
Created February 10, 2010 at 2:09 AM
Updated September 7, 2017 at 7:57 AM
Resolved September 7, 2017 at 7:57 AM
Who's Looking?