geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Changes to OpenEJB interceptor stack
Date Wed, 26 May 2004 01:43:35 GMT
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 <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