geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject RE: Changes to OpenEJB interceptor stack
Date Wed, 26 May 2004 01:45:37 GMT
This may not work for my security interceptors since the threadlocal
context may be set by something external to OpenEJB.

> -----Original Message-----
> From: Dain Sundstrom [mailto:dsundstrom@gmail.com]
> Sent: Tuesday, May 25, 2004 8:16 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: Changes to OpenEJB interceptor stack
> 
> 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