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: [openejb-dev] Re: Cut date for 1.1?
Date Mon, 23 Jan 2006 22:21:36 GMT

On Jan 22, 2006, at 5:58 PM, David Jencks wrote:

>
> On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote:
>>>> 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.


Dain's on the road again, but I have seen some of the code and try  
and recall what I can.   From the choices, I'd say it's closer to 1  
than 2.  I distinctly remember a very impressive looking map  
implementation that was type safe in it's understanding of methods.   
IIRC it was an object array, not a true map, that gave you method ->  
object indexing ability.  Something of that nature.

The motivation is something I can speak a little more about as it's  
basically a lot of design concepts we found useful in the past.  I  
think he just got sick of hearing me talk about it and decided to  
give it a try :)  The idea being to split the ejb specific stuff from  
the stuff that is not entirely ejb specific, but likely more specific  
to beans of that type.  So things like pool settings, or caching  
settings could just be configured generally and not over and over  
again on a per-ejb basis.  You can do more at a macroscopic level and  
are forced to do less at a microscopic level.  The bean type  
information goes to the container (which could be implemented as a  
stack of interceptors) and the bean specific information goes into  
the ejb context object.  For people who know OpenEJB 1, that would be  
DeploymentInfo (bad name) and Container.

Surprisingly, it cleans up your code quite a bit to separate concerns  
at that level and allows you some great config options.  Say for  
example, you could tweak the pool size for all the stateless session  
beans running in a given container via a management console.  No need  
to grab each bean individually and set it's pool size.  It also  
allows you to easily leverage new container implementations.  For  
example, when we ran the ejb test suite at ApacheCon 2003 that was  
basically the "nova" containers wrapped with an adapter and used in  
an unmodified OpenEJB 0.9.2 distribution.

Adhering to the idea that simple things should be simple and complex  
things possible, if you did want to be very specific and microscopic  
in the management of a particular ejb, you just dedicate a new  
container definition to that ejb (i.e. a container with one ejb).  An  
easy way to do that would be via another gbean declaration which you  
could probably put right in the openejb-jar.xml file if you wanted.   
That's where all the information lays now so it isn't entirely  
different.

Anyway, that's the big picture from my eyes.

-David





Mime
View raw message