You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2008/10/15 20:16:44 UTC

[jira] Reopened: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems

     [ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks reopened GERONIMO-4350:
------------------------------------

      Assignee: Dain Sundstrom  (was: David Jencks)

The problem was in the (admittedly extremely badly written) resource adapter, not application code.  I can't find any parts of the spec that prohibit a ConnectionFactory from assuming that what it gets from the ConnectionManager.allocateConnection is the same object that the ManagedConnection.getConnection(...) produced.  Can you point to the part of the spec you're thinking of? Or, in fact, any part of the spec that indicates why you have to specify interfaces as well as implementation classes for connection factory and connection?

> Connection proxying to imitate DissociatableManagedConnection can easily cause problems
> ---------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-4350
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-4350
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 2.1, 2.2
>            Reporter: David Jencks
>            Assignee: Dain Sundstrom
>             Fix For: 2.1.4, 2.2
>
>
> We have some code to imitate the DissociatableManagedConnection to avoid connection leaks that proxies connections from the supplied ManagedConnectionFactory: the proxy implements all the interfaces of the connection, but not the class itself.  However, there's nothing stopping the ConnectionFactory from casting the (now proxied) connection to the implementation class it expects.
> The TxConnect project at sourceforge illustrates this approach in the EisConnectionFactory.
> http://txconnect.sourceforge.net
> One possible solution would be to have a flag to turn on this proxying behavior.  I don't immediately see a way to detect if the problem will occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.