interaction of connector framework with interceptor chains

[David Jencks <da...@coredevelopers.net>]

I'm refactoring the outbound ConnectionManager framework to reduce the 
number of synchronization blocks needed.  In order to do this the 
connector framework needs to rely on some services to be provided by 
the interceptor chain framework for the objects using the connections.

These dependencies are:

1. Keeping track of which connection handles are held by which object.  
This can be done by storing them in the ejb instance context-like 
object.

2. Keeping track of which managed connections are enrolled in which 
transaction.  This can be done by storing them in a transaction 
context-like object.

This would be completely straightforward if Geronimo only supported one 
style of interceptor chain, as I could simply code the functionality in 
to it.

However, Geronimo is supposed to support multiple ejb containers (as 
well as other things), and the current ejb container is not even part 
of Geronimo.

So, what I'm doing so far is to define interfaces for the support the 
connector framework needs from the interceptor chain framework, and to 
provide a "default" implementation in geronimo to show what needs to 
happen inside the interceptor chain framework (and possibly provide for 
implementation by delegation in a real interceptor chain framework).

I'll then implement these interfaces in the OpenEJB Nova interceptor 
chain framework.  This will have the effect of tying the OpenEJB Nova 
interceptor chain framework into the Geronimo connection management 
framework unless we find a way to customize the creation of interceptor 
stacks in Nova.

I realize it's probably unclear what I'm talking about without seeing 
the code, but I wanted to at least mention my approach in case there 
are strong objections or other ideas on how to proceed.

There will still be one (or two) synchronized block in the pooling 
code, when it is necessary to get a managed connection out of the pool 
(or put it back).  I don't know how to eliminate this, if anyone does 
please let me know.  This should normally occur only once per 
transaction, however.

Thanks
david jencks

Re: interaction of connector framework with interceptor chains

[David Jencks <da...@coredevelopers.net>]

I've committed this work, in both Geronimo and Nova, and would welcome 
comments.

It is very likely that these changes break using connections from 
servlets/jsps inside a UserTransaction.
I'm considering various possible solutions for this.

thanks
david jencks

On Saturday, December 6, 2003, at 12:08 PM, David Jencks wrote:

> I'm refactoring the outbound ConnectionManager framework to reduce the 
> number of synchronization blocks needed.  In order to do this the 
> connector framework needs to rely on some services to be provided by 
> the interceptor chain framework for the objects using the connections.
>
> These dependencies are:
>
> 1. Keeping track of which connection handles are held by which object. 
>  This can be done by storing them in the ejb instance context-like 
> object.
>
> 2. Keeping track of which managed connections are enrolled in which 
> transaction.  This can be done by storing them in a transaction 
> context-like object.
>
> This would be completely straightforward if Geronimo only supported 
> one style of interceptor chain, as I could simply code the 
> functionality in to it.
>
> However, Geronimo is supposed to support multiple ejb containers (as 
> well as other things), and the current ejb container is not even part 
> of Geronimo.
>
> So, what I'm doing so far is to define interfaces for the support the 
> connector framework needs from the interceptor chain framework, and to 
> provide a "default" implementation in geronimo to show what needs to 
> happen inside the interceptor chain framework (and possibly provide 
> for implementation by delegation in a real interceptor chain 
> framework).
>
> I'll then implement these interfaces in the OpenEJB Nova interceptor 
> chain framework.  This will have the effect of tying the OpenEJB Nova 
> interceptor chain framework into the Geronimo connection management 
> framework unless we find a way to customize the creation of 
> interceptor stacks in Nova.
>
> I realize it's probably unclear what I'm talking about without seeing 
> the code, but I wanted to at least mention my approach in case there 
> are strong objections or other ideas on how to proceed.
>
> There will still be one (or two) synchronized block in the pooling 
> code, when it is necessary to get a managed connection out of the pool 
> (or put it back).  I don't know how to eliminate this, if anyone does 
> please let me know.  This should normally occur only once per 
> transaction, however.
>
> Thanks
> david jencks
>