[jboss-jira] [JBoss JIRA] Commented: (JBJCA-593) AbstractPool returns the wrong ConnectionListener if more than one ManagedConnectionPools are used in a given transaction
Matt Drees (JIRA)
jira-events at lists.jboss.org
Wed Jun 1 16:28:00 EDT 2011
[ https://issues.jboss.org/browse/JBJCA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605893#comment-12605893 ]
Matt Drees commented on JBJCA-593:
----------------------------------
Doh, my new test method names have a typo. If you apply this patch, please change "Reqeusts" to "Requests".
> AbstractPool returns the wrong ConnectionListener if more than one ManagedConnectionPools are used in a given transaction
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-593
> URL: https://issues.jboss.org/browse/JBJCA-593
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.0.Beta6
> Reporter: Matt Drees
> Assignee: Jesper Pedersen
> Attachments: fix-jta-integration-against-rev-111501.diff
>
>
> The way that AbstractPool uses the TransactionSynchronizationRegistry appears to be incorrect.
> I discovered that if two XA pools exist and both are used in a transaction, the second pool hands out a reference to the first pool's ConnectionListener in getTransactionOldConnection().
> The reason is that AbstractPool uses TSR.getResource() and TSR.putResource() using a key based on the current Transaction. When the second pool checks for an existing connection, it uses the same key as the first pool (since it exists in the same transaction).
> I believe the correct approach is to use a key that is based on the relevant ManagedConnectionPool instead of the current Transaction.
> A patch with tests will be added soon.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list