Pool should not yield a connection with an ongoing transaction

                 Key: DNET-793
                 URL: http://tracker.firebirdsql.org/browse/DNET-793
             Project: .NET Data provider
          Issue Type: Bug
          Components: ADO.NET Provider
    Affects Versions:
         Environment: Windows 10 64bit, local Firebird server
            Reporter: Frédéric Delaporte
            Assignee: Jiri Cincura
            Priority: Minor

In distributed transaction cases, the transaction completion occurs 
asynchronously and concurrently to code following the transaction scope 

In such case, it is possible to release the connection to the pool while its 
transaction is still ongoing, without having any clue about that. And 
requesting a connection from pool may then yield a connection still having an 
ongoing transaction.
Trying to begin a new transaction on it then fails with error: 
System.InvalidOperationException : A transaction is currently active. Parallel 
transactions are not supported.

Granted, that is a wicked case.

See https://github.com/npgsql/npgsql/issues/1571#issuecomment-308651461 
discussion with a Microsoft employee: when distributed, MSDTC considers a 
transaction to be committed once it has collected all participant votes for 
committing from prepare phase. It then immediately notifies all participants of 
the outcome. This causes TransactionScope.Dispose to leave while the second 
phase of participants may still be executing. This means the transaction from 
the db view point can still be pending and not yet committed after the scope 
disposal. This is by design of MSDTC and we have to cope with that.
Some data provider may have a global locking mechanism causing any subsequent 
connection use to wait for the end of the commit phase, but this is not a 
general case. Such a mechanism has been put in place for NHibernate own 
volatile resource, but this only guarantee us that this NHibernate resource has 
ended its processing, it does not guarantee us that is the case of the Firebird 

This causes a number of NHibernate tests to fail with Firebird regularly but 
not consistently.

A test case pattern for this would likely be like the 
 test of Npgsql. There are more wicked cases involving distributed transaction 
in this test file, it may be worth checking them with Firebird too.
(For information, Npgsql checks distributed transaction status on connection 
when closed for avoiding returning them to pool if the transaction is not 
ended, something like just flagging them as having to return to pool once their 
transaction completion event finally gets executed. This avoid at least the 
pool trouble but not some other issues like trying to reuse the same connection 
immediately after a distributed scope disposal.)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-net-provider mailing list

Reply via email to