geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dain Sundstrom (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems
Date Fri, 10 Oct 2008 21:31:44 GMT

    [ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638652#action_12638652
] 

Dain Sundstrom commented on GERONIMO-4350:
------------------------------------------

I'm not sure I understand the problem.  IIRC, a spec-compliant RA is required to list all
interfaces that are needed by calling code (so we know what to add to the proxy).

Anyway, if this is something we want/need to support, I can this of a few workarounds/solutions
(listed in order of difficulty for Geronimo):

1) add a getDelegate method one of the interfaces like JDBC and JPA use
2) add a flag to turn of connection GC
3) rewrite the connection pool code to use weak references for garbage detection

Option 3 is the most reliable but a lot more work.

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


Mime
View raw message