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.
-dain 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 > >
