Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <1393618775.1224063104358.JavaMail.jira@brutus>
Date: Wed, 15 Oct 2008 02:31:44 -0700 (PDT)
From: =?utf-8?Q?J=C3=BCrgen_Weber_=28JIRA=29?= <jira@apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Commented: (GERONIMO-4350) Connection proxying to imitate
 DissociatableManagedConnection can easily cause problems
In-Reply-To: <75020589.1223658104349.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/GERONIMO-4350?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
2639780#action_12639780 ]=20

J=C3=BCrgen Weber commented on GERONIMO-4350:
----------------------------------------

The analysis of David Jencks is good, thanks very much.

I changed EisConnectionFactory so it uses IEisConnection instead of the imp=
lementation EisConnection and an txconnector works now=20
(http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisCo=
nnection-td19610387s134.html)

> 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)=20
>          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 ManagedConnecti=
onFactory: the proxy implements all the interfaces of the connection, but n=
ot the class itself.  However, there's nothing stopping the ConnectionFacto=
ry from casting the (now proxied) connection to the implementation class it=
 expects.
> The TxConnect project at sourceforge illustrates this approach in the Eis=
ConnectionFactory.
> http://txconnect.sourceforge.net
> One possible solution would be to have a flag to turn on this proxying be=
havior.  I don't immediately see a way to detect if the problem will occur.

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