On Tue, May 25, 2004 at 08:16:06PM -0500, Dain Sundstrom wrote: > I like this design, and I think we should immediately switch to the > single thread local. This is an optimization we know will have to > make so we might as well do it now.
This thread local approach is the way OpenEJB 1.0 does things. One thread local containing a single object that could get you anything you wanted. I'm fine going back to that approach (the 2.0 code is a little slower than the 1.0 code), but caution that it will implicitly couple all the interceptors on another object besides Invocation and InvocationResult and would add a dependency on openejb-core. Last time we tried to avoid a dependency on the OpenEJB TransactionContext class we ended up moving a whole tree of objects into Geronimo that Geronimo doesn't even use, including container-managed transaction support and other OpenEJB specific things. -David > On Tue, 25 May 2004 20:51:02 -0400, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > > > > -----Original Message----- > > > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > > > > > Posted here as its really about how it integrates with the Geronimo > > > environment. > > > > > > We have a problem with certain callbacks like ejbLoad & ejbStore not > > > being invoked with the correct context - things like > > > AccessControlContext for thread and support for connection handle > > > tracking. > > > > > > One solution seems to be to eliminate the direct calls into the EJBs > > and > > > replace them with invocations that go down the interceptor stack - > > > basically converting the callbacks into VOPs and handling them in the > > > same way as business methods. > > > > > > The VOP would be responsible for setting up the environment *specific > > to > > > the individual method.* This would include: > > > * the appropriate EJBContext state > > > * the AccessControlContext of the thread - in other words the > > > switch from container code to application code for the purpose > > > of sandboxing, possibly calling doP > > > > > > Just before Dispatch, there would be a collection of interceptors that > > > applied for both client and container initiated invocations. These > > would > > > include: > > > * JNDI component context > > > * Connection handle tracking > > > > > > *Every* invocation would need to go through these - this would > > include, > > > for example, the calls to ejbStore performed at a sync point (e.g. on > > > query or at the end of a tx). > > > > > > The top of the stack would contain the interceptors that dealt with > > > invocations from clients: > > > * Instance location > > > * Transaction context > > > * Security identity - determine which identity should be used when the > > > instance is invoked, the caller or the run-as identity > > > * System exception handling > > > > > > These interceptors manage things that apply to all J2EE components - > > > servlets as well as EJBs. These are: > > > * JNDI component context > > > * Connection handle tracking > > > * Thread identity > > > * Transaction context > > > > > > These are all handled by separate ThreadLocals right now, which > > provides > > > a clean separation between the different handlers but at the cost of > > > needing to initialize them all separately. It seems to be easier to > > set > > > up a 'ComponentThreadInstanceContext' (bad name) which would provide > > > access to all this information from one place. On the other hand, this > > > is really a performance optimization so perhaps should be deferred. > > > > > > Thoughts? > > > > Seems like a good idea to me. I also share your reservations and think > > that we should stick with separate ThreadLocals for the moment. > > > > Regards, > > Alan > > > >
