[jboss-jira] [JBoss JIRA] Commented: (JBAS-4667) Wrong logic in CachedConnectionManager.getCloseConnectionSynchronization()
[ http://jira.jboss.com/jira/browse/JBAS-4667?page=comments#action_12375380 ]
Adrian Brock commented on JBAS-4667:
------------------------------------
The patch looks correct to me, but I don't really understand how it can happen in
reality.
The method is only invoked in two places.
1) At the end of an EJB invocation in a transaction to defer connection close checking
to the end of the transaction, i.e. add all the unclosed handles to a transaction
synchronization
to be checked after the commit.
This is for the anti-pattern of holding handles throughout a transaction.
Using transaction affinity on the connection factory (<track-connection-by-tx/> in
JBoss)
and closing handles before exiting ejb methods
is the way you should do it, not thread locals or caching in the hibernate session, etc..
2) The later closing of the deferred connections before the commit occurs
I don't see how this could relate to prepare? I can see how it might relate to a
transaction
that got into a rollback only state between ejb methods with the connection handle cached
across those invocations?
Wrong logic in
CachedConnectionManager.getCloseConnectionSynchronization()
--------------------------------------------------------------------------
Key: JBAS-4667
URL: http://jira.jboss.com/jira/browse/JBAS-4667
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.2.1.GA
Reporter: Oleg Nitz
If the tx is not active (for example it has STATUS_PREPARING), then the method always
returns null, even if the associated CloseConnectionSynchronization exists.
This results in wrong warnings about non-closed connections, since when the close() is
called for a connector, in CachedConnectionManager.unregisterConnection() a null value is
returned from getCloseConnectionSynchronization() and the connector remains in the list of
non-closed resources for the transaction.
I think this bug was introduced here:
http://jira.jboss.com/jira/browse/JBAS-31#action_12310798
I propose the following solution:
--- CachedConnectionManager.java.orig 2005-11-22 02:10:41.000000000 +0200
+++ CachedConnectionManager.java 2007-09-04 18:42:48.000000000 +0300
@@ -544,13 +544,13 @@
try
{
Transaction tx = tm.getTransaction();
- if (TxUtils.isActive(tx))
+ if (tx != null)
{
TransactionSynchronizer.lock(tx);
try
{
CloseConnectionSynchronization cas = (CloseConnectionSynchronization)
TransactionSynchronizer.getCCMSynchronization(tx);
- if (cas == null && createIfNotFound)
+ if (cas == null && createIfNotFound &&
TxUtils.isActive(tx))
{
cas = new CloseConnectionSynchronization();
TransactionSynchronizer.registerCCMSynchronization(tx, cas);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira