geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject interaction of connector framework with interceptor chains
Date Sat, 06 Dec 2003 20:08:22 GMT
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


Mime
View raw message