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
