[jboss-jira] [JBoss JIRA] Commented: (JBAS-5095) Race condition between connection.close() and transaction.rollback() causes connection leak

[Adrian Brock (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12421481#action_12421481 ] 

Adrian Brock commented on JBAS-5095:
------------------------------------

I've moved this to 4.2.4 to fix properly.

The problem is fixed in 4.2.3 but only with an ugly workaround that produces a 
WARNing when it occurs.

The correct fix is to make the two checks 
number of handles=0 and 
connection is no longer track-by-tx
atomic in the two different places where it occurs.

This became an issue with JBossTM in 4.2.0+ where a connection.close() can race with a transaction.rollback()
due to a transaction timeout.

> Race condition between connection.close() and transaction.rollback() causes connection leak
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5095
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5095
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.2.2.GA
>            Reporter: Adrian Brock
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA
>
>
> There is a race condition between the connection.close() and an asynchronous transaction completion
> (e.g. transaction timeout) that can lead to a leaked connection permit with eventual pool exhaustion
> when using track-connection-by-tx (i.e. all local resources).
> The problem is caused in the TxConnectionManager where the unregister assoication and the afterCompletion
> are not synchronized with each other. Both can see the connection as ready to return to the pool
> (one removes the handle, the other the synchronization at about the same time so they both check
> the same state) and both do it.
> The InternalManagedConnectionPool does not check for duplicate returns and uses an ArrayList to
> store connections (for the MRU behaviour). So the connection ends up in the pool twice
> This eventually causes problems like the leaked permit.

-- 
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