geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: Changes to OpenEJB interceptor stack
Date Wed, 26 May 2004 00:51:02 GMT

> -----Original Message-----
> From: Jeremy Boynes []
> 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
> 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
> 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
> include:
> * JNDI component context
> * Connection handle tracking
> *Every* invocation would need to go through these - this would
> 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
> a clean separation between the different handlers but at the cost of
> needing to initialize them all separately. It seems to be easier to
> 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.


View raw message