[jbossts-issues] [JBoss JIRA] Commented: (JBTM-789) XA connections leak when no modifier available

[Mauro Molinari (JIRA)]

    [ https://jira.jboss.org/browse/JBTM-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12552721#action_12552721 ] 

Mauro Molinari commented on JBTM-789:
-------------------------------------

Anyway, my own experience (working with Oracle, SQL Server and PostgreSQL) is that the right decision is to always delay the connection closing after the transaction termination. Closing the connection immediately can lead to problems if the connection is actually a pooled connection: in fact, closing it immediately means returning it to the pool, so that it could be borrowed by some other transaction while the first one (to which it is still bound) is still in progress.

> XA connections leak when no modifier available
> ----------------------------------------------
>
>                 Key: JBTM-789
>                 URL: https://jira.jboss.org/browse/JBTM-789
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA
>    Affects Versions: 4.11.0
>         Environment: JBoss Transactions 4.11, Tomcat, Spring
>            Reporter: Mauro Molinari
>
> I recently upgraded JBossTS from 4.6.1 GA to 4.11 Final. I see that bug JBTM-532 that I opened against 4.5 and 4.6 should have been fixed in 4.8.0. However, besides still having a null _theModifier when using PostgreSQL, the current (4.11) implementation of com.arjuna.ats.internal.jdbc.ConnectionImple.close() has a problem.
>  
> I mean, if _theModifier is null, a comment says: "no indication about connections, so assume close immediately". However in this case only _theConnection (java.sql.Connection) is closed and set to null, while _recoveryConnection.closeCloseCurrentConnection() is not called, leading to an XAConnection leak.
> What I would expect is that if _theModifier is null, a log entry were added but nothing else were done; in particular I would expect not to return and let the following "if (!delayClose)" (towards the end of the method) close both the connections immediately.

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