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.
thanks
david jencks
-dain
