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/10 19:01:44 UTC
[jira] Created: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
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.
[jira] Commented: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dain Sundstrom closed GERONIMO-4350.
------------------------------------
Resolution: Invalid
Assignee: David Jencks (was: Dain Sundstrom)
The problem was in user code that was attempting to downcast a connection proxy to a specific implementation class which is not allowed by the JEE Connector specification.
> 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: David Jencks
> 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.
[jira] Reopened: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (GERONIMO-4350) Connection proxying to
imitate DissociatableManagedConnection can easily cause problems
Posted by "Jürgen Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639780#action_12639780 ]
weberjn edited comment on GERONIMO-4350 at 10/15/08 2:36 AM:
------------------------------------------------------------------
The analysis of David Jencks is good, thanks very much.
I changed EisConnectionFactory so it uses IEisConnection instead of the implementation EisConnection and txconnect.sourceforge.net works now
(http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-td19610387s134.html)
was (Author: weberjn):
The analysis of David Jencks is good, thanks very much.
I changed EisConnectionFactory so it uses IEisConnection instead of the implementation EisConnection and an txconnector works now
(http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-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)
> 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.
[jira] Commented: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "Jürgen Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639780#action_12639780 ]
Jürgen 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 implementation EisConnection and an txconnector works now
(http://www.nabble.com/%24Proxy33-cannot-be-cast-to-com.dsoft.jca.eis.EisConnection-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)
> 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.
[jira] Updated: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jarek Gawor updated GERONIMO-4350:
----------------------------------
Affects Version/s: 2.1.4
Fix Version/s: (was: 2.1.4)
Updating versions as it probably will not get fixed for 2.1.4.
> 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.1.4, 2.2
> Reporter: David Jencks
> Assignee: Dain Sundstrom
> Fix For: 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.
[jira] Updated: (GERONIMO-4350) Connection proxying to imitate
DissociatableManagedConnection can easily cause problems
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated GERONIMO-4350:
-----------------------------------
Fix Version/s: (was: 2.2)
Wish List
unlikely to get resolved any time soon.
> 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.1.4, 2.2
> Reporter: David Jencks
> Assignee: Dain Sundstrom
> Fix For: Wish List
>
>
> 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.