geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Cut date for 1.1?
Date Mon, 23 Jan 2006 01:58:54 GMT

On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote:

> This is really a discussion for the openejb mailing list, but since  
> you asked here I'll respond here.
> On Jan 20, 2006, at 11:17 AM, David Jencks wrote:
>> On Jan 20, 2006, at 9:59 AM, Dain Sundstrom wrote:
>>> On Jan 20, 2006, at 9:46 AM, David Jencks wrote:
>>>> Personally I am not ready for 1.1 to be frozen.
>>>> Also, there is at least one major bug (tomcat cross-context  
>>>> dispatch) that needs to be fixed and I haven't seen any progress  
>>>> on it.
>>>> The nature of your change might affect other peoples opinion on  
>>>> this also, what are you planning?
>>> I am working on splitting the OpenEJB container into one object  
>>> for each deployed ejb and a set of share invocation processing  
>>> ejb containers.  This is a refactoring of internal interfaces  
>>> well below the layer our users see.
>> Does this mean there will be one interceptor stack for each ejb  
>> type, shared among all the e.g. stateless sesssion ejbs?
> By default, yes. The idea is you can deploy extra invocation  
> processors that have different QoSes configured and then you assign  
> an ejb to the processor you want.
>> What is the advantage of this design?
> I think the important important advantage for OpenEJB is that this  
> change aligns the 2 code with the 1 code.  The other big advantage  
> is that it the job of a deployer is simpler because the most  
> complex configurations (like caches) are placed on the invocation  
> processors which will be defined using he generic gbean xml tags.
>> I can think of some disadvantages compared to our present design  
>> but no advantages.  Probably just a lack of imagination, but I'd  
>> really appreciate discussion of architectural changes before the  
>> code arrives.
> The architectural change is to split the current EJB container into  
> a service for each EJB and a shared service for invocation  
> processing.  If you want to have a discussion on this, we should  
> move to the openejb dev mailing list.

I thought about this several years ago in reference to another app  
server and thought of 2 designs.  I'm curious if you picked one or  
found a third, and your reasons.  I'll describe the designs in terms  
of gbeans for simplicity.

1. The gbeans themselves form the interceptor stack.  This means the  
ejb gbean needs to  have an ejb context object that it sends down the  
stack with each call containing the info particular to that ejb, such  
as the transaction policy settings.  Since you don't really have any  
idea what interceptors are present, AFAICT you either need to code  
generate a context object to suit the particular interceptors  
present, or use a map.  A map is a bit slow and loses type safety,  
whereas code generation seems awfully complicated.  I suppose it  
might be possible to use an Object[] and figure out the indices for  
each interceptor when the ejb starts.

2. The gbeans are interceptor factories, and when the ejb starts it  
uses the factories to construct its own personalized interceptor  
stack.  Here, each interceptor instance can hold the context  
information for itself, and initializing it from a map does not have  
a performance penalty.  On the other hand, you get more interceptor  
object instances.

david jencks

> -dain

View raw message