[
https://issues.apache.org/jira/browse/GERONIMO-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739828#action_12739828
]
David Jencks commented on GERONIMO-4786:
----------------------------------------
Rev 801468 appears to fix the connection leak but it may introduce other
problems. Also needs porting to txmanager trunk.
> Mulitple connections outside UserTransaction result in ManageConnection leak
> ----------------------------------------------------------------------------
>
> Key: GERONIMO-4786
> URL: https://issues.apache.org/jira/browse/GERONIMO-4786
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: connector
> Affects Versions: 2.2
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: 2.2
>
>
> This results in a ManagedConnection not being returned to the pool:
> ConnectionFactory cf = (look it up)
> Connection c1 = cf.createConnection();
> Connection c2 = cf.createConnection();
> UserTransaction ut = (lookup)
> ut.begin()
> What happens is that the transaction manager starts enlisting the
> connections. The first one gets set up as the shared connection. For the
> second one, we just install the shared ManagedConnection without checking
> that there is none there already.
> I tried returning any existing ManagedConnection but that doesn't work with
> AMQ or other j2ca implementations that don't have dissociatable connections.
> I think the best option is to keep using any other existing connections but
> treat them as unshared.
> In case you are wondering why anyone would do this.... If you are using the
> jms 1.0 apis you might get a QueueConnection and a TopicConnection at the
> same time.
> Fix is in the txmanager component, not in geronimo itself. This should be
> applicable to g 2.1 and 2.2 and the 2.1 and trunk branches of the txmanager
> component.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
