association between ManagedConnection and Connection

[Joerg Heinicke]

Hello guys,

I have implemented an AbstractManagedConnection and an AbstractConnection
following the implementation in TranQL codebase (also
AbstractManagedConnection/ManagedConnectionHandle and ConnectionHandle), but
without the JDBC-specific parts. Due to a failing test case of myself I
wondered about an implementation detail, which might not work, but is
difficult to test or check for. It would also apply to the TranQL code.

In ConnectionHandle there is a method getManagedConnection() calling
associateConnection(Object, ManagedConnectionFactory, ConnectionRequestInfo)
on a LazyAssociatableConnectionManager instance. In my case it is
GeronimoConnectionManager used in combination with Jencks as described at
http://jroller.com/page/Templth/20051123. Unfortunately the check for
non-null ManagedConnection fails as GeronimoConnectionManager handles the
association internally, but does not call any method on the
ManagedConnectionFactory or the ManagedConnection as I expected it.

Now I don't know if this just does not happen for the initial association or
always (that's what's difficult to test). The difference in my code to the
TranQL's code was the missing initial association at
AbstractManagedConnection.getConnection(Subject, ConnectionRequestInfo):
  handle.setAssociation(this);
  handles.add(handle);
I wondered why it should not work without it as the Connection should by
lazily associatable. What I expected was a call to
ManagedConnectionFactory.matchManagedConnection(..) to get a matching
ManagedConnection and a call to
ManagedConnection.associateConnection(Object) to finally associate it.
Unfortunately GeronimoConnectionManager seems to be of different opinion.

WDYT?

Jörg

--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

[djencks]

On Jan 24, 2006, at 2:54 AM, Jörg Heinicke wrote:

> Hello guys,
>
> I have implemented an AbstractManagedConnection and an  
> AbstractConnection
> following the implementation in TranQL codebase (also
> AbstractManagedConnection/ManagedConnectionHandle and  
> ConnectionHandle), but
> without the JDBC-specific parts. Due to a failing test case of  
> myself I
> wondered about an implementation detail, which might not work, but is
> difficult to test or check for. It would also apply to the TranQL  
> code.
>
> In ConnectionHandle there is a method getManagedConnection() calling
> associateConnection(Object, ManagedConnectionFactory,  
> ConnectionRequestInfo)
> on a LazyAssociatableConnectionManager instance. In my case it is
> GeronimoConnectionManager used in combination with Jencks as  
> described at
> http://jroller.com/page/Templth/20051123. Unfortunately the check for
> non-null ManagedConnection fails as GeronimoConnectionManager  
> handles the
> association internally, but does not call any method on the
> ManagedConnectionFactory or the ManagedConnection as I expected it.
>
> Now I don't know if this just does not happen for the initial  
> association or
> always (that's what's difficult to test). The difference in my code  
> to the
> TranQL's code was the missing initial association at
> AbstractManagedConnection.getConnection(Subject,  
> ConnectionRequestInfo):
>   handle.setAssociation(this);
>   handles.add(handle);
> I wondered why it should not work without it as the Connection  
> should by
> lazily associatable. What I expected was a call to
> ManagedConnectionFactory.matchManagedConnection(..) to get a matching
> ManagedConnection and a call to
> ManagedConnection.associateConnection(Object) to finally associate it.
> Unfortunately GeronimoConnectionManager seems to be of different  
> opinion.
>
> WDYT?

I think your adapter is not working properly and it should keep track  
of the handles it has handed out until geronimo calls  
dissociateConnections() on the DissociatableManagedConnection.  
However, I think we ought to be able to adapt to your adapters  
bug :-) and return the managed connection the handle is actually  
associated with.  Can you supply a test case to make this easier to  
figure out what is going on?  Filing a bug at geronimo would also be  
fine.

thanks
david jencks

>
> Jörg
>
> --
> 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
> +++ GMX - die erste Adresse für Mail, Message, More +++

[Joerg Heinicke]

> Von: David Jencks <david_jencks_at_yahoo.com>
> Datum: Tue, 24 Jan 2006 15:35:26 -0800
>
> I think your adapter is not working properly and it should keep track  
> of the handles it has handed out until geronimo calls  
> dissociateConnections() on the DissociatableManagedConnection.  
> However, I think we ought to be able to adapt to your adapters  
> bug :-) and return the managed connection the handle is actually  
> associated with.  Can you supply a test case to make this easier to  
> figure out what is going on?  Filing a bug at geronimo would also be  
> fine.

Hello David,

I don't think this is really needed. It was more a question of understanding
how it has to work. And as I wrote my implementation follows the TranQL's
one (really closely).

What I observed with my test was the fact that the ManagedConnection must be
associated with the Connection initially by hand (as happening at [1], line
172) as otherwise the Connection would miss the reference to the
ManagedConnection.

What I thought what should work too is the removal of the initial
association by hand, because the Connection is lazily associatable (or what
TranQL calls DissociatableConnectionHandle to speak in interfaces) and finds
its associated ManagedConnection when calling getManagedConnection() [2].

Unfortunately this does not work as the GeronimoConnectionManager does not
interact with the Connection or the ManagedConnection. Maybe it just assumes
that both are associated initially and so the call to associateConnection()
[3] does not have any effect. This would explain the observed behaviour. It
probably behaves differently after the Connection and the ManagedConnection
have been dissociated by the ConnectionManager by calling
dissociateConnections() as you wrote above.

Is my original question more clear now? It was more or less a check if "lazy
connection association" really works, which is difficult to test. An easy
test would have been to remove the initial association. So if you need a
test case it should be sufficient to remove line 172 in
AbstractManagedConnection [1].

Thanks and regards

Jörg

[1]
http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/connector/AbstractManagedConnection.java?annotate=1.6#172
[2]
http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/connector/jdbc/ConnectionHandle.java?annotate=1.5#57
[3]
http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/connector/jdbc/ConnectionHandle.java?annotate=1.5#64

--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

[djencks]

On Jan 25, 2006, at 2:12 AM, Jörg Heinicke wrote:

>> Von: David Jencks <david_jencks_at_yahoo.com>
>> Datum: Tue, 24 Jan 2006 15:35:26 -0800
>>
>> I think your adapter is not working properly and it should keep track
>> of the handles it has handed out until geronimo calls
>> dissociateConnections() on the DissociatableManagedConnection.
>> However, I think we ought to be able to adapt to your adapters
>> bug :-) and return the managed connection the handle is actually
>> associated with.  Can you supply a test case to make this easier to
>> figure out what is going on?  Filing a bug at geronimo would also be
>> fine.
>
> Hello David,
>
> I don't think this is really needed. It was more a question of  
> understanding
> how it has to work. And as I wrote my implementation follows the  
> TranQL's
> one (really closely).
>
> What I observed with my test was the fact that the  
> ManagedConnection must be
> associated with the Connection initially by hand (as happening at  
> [1], line
> 172) as otherwise the Connection would miss the reference to the
> ManagedConnection.
>
> What I thought what should work too is the removal of the initial
> association by hand, because the Connection is lazily associatable  
> (or what
> TranQL calls DissociatableConnectionHandle to speak in interfaces)  
> and finds
> its associated ManagedConnection when calling getManagedConnection
> () [2].
>
> Unfortunately this does not work as the GeronimoConnectionManager  
> does not
> interact with the Connection or the ManagedConnection. Maybe it  
> just assumes
> that both are associated initially and so the call to  
> associateConnection()
> [3] does not have any effect. This would explain the observed  
> behaviour. It
> probably behaves differently after the Connection and the  
> ManagedConnection
> have been dissociated by the ConnectionManager by calling
> dissociateConnections() as you wrote above.
>
> Is my original question more clear now? It was more or less a check  
> if "lazy
> connection association" really works, which is difficult to test.

I agree :-).  I last looked at this more than a year ago, and seem to  
remember we had some evidence that lazy connection association did  
work then, but I think we need an explicit test case for it in  
geronimo.  At this point I'm not too confident in claiming that it  
works.  I'll see if I can think one up and add it.

thanks
david jencks

> An easy
> test would have been to remove the initial association. So if you  
> need a
> test case it should be sufficient to remove line 172 in
> AbstractManagedConnection [1].
>
> Thanks and regards
>
> Jörg
>
> [1]
> http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/ 
> connector/AbstractManagedConnection.java?annotate=1.6#172
> [2]
> http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/ 
> connector/jdbc/ConnectionHandle.java?annotate=1.5#57
> [3]
> http://cvs.tranql.codehaus.org/connector/src/java/org/tranql/ 
> connector/jdbc/ConnectionHandle.java?annotate=1.5#64
>
> --
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner