geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gmail.com>
Subject Re: Changes to OpenEJB interceptor stack
Date Wed, 26 May 2004 01:16:06 GMT
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 <adc@toolazydogs.com> wrote:
> 
> > -----Original Message-----
> > From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> >
> > 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
> 
>

Mime
View raw message