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: 5.11.0.0
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
disposal.
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
one.
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
[DistributedRollback|https://github.com/npgsql/npgsql/blob/dev/test/Npgsql.Tests/SystemTransactionTests.cs#L204]
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:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
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
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
