Richard,
I very much agree with your comment that it is possible to implement the
EJB Container in a way that supports fine grained, fast access Entity beans.
I just want to point out that this is actually possible even with EJB 1.1,
not just EJB 2.0. You mention a number of limitations in EJB 1.1:
* Lack of support for optimistic concurrency
* Lack of support for lazy loading
Neither of these capabilities is really missing in EJB 1.1. Witness, for
example, that our product has provided correct optimistic concurrency since
its inception, using EJB 1.1. Lazy loading is harder to achieve in EJB 1.1,
but can be done using post-processing of byte-code. I know of at least one
CMP 1.1 engine that provides this capability.
Others cite as problems in EJB 1.1 the find/load division of labor. Again,
although this is a problem for BMP (FatKeys notwithstanding), this is clearly
solvable using EJB 1.1 CMP (as evidenced by the fact that many product now
support it). In short, almost all of the "problems" that appear to be solved
by the introduction of the new programming model in EJB 2.0 were actually
solvable in EJB 1.1. No product solved all the problems (that I am aware of),
but various products did solve various subsets.
In fact, the only true limitation to supporting fine grained EBs in EJB 1.1
is the argument passing rules. This was called out as the primary motivation
for moving to the local interface model. But I believe people tend to even
overestimate the performance impact of this problem. To understand this
problem better, it is useful to examine all the various arguments types which
need to be passed into/out of an EJB:
1) Primitives (int)
2) Primitive wrappers (Integer)
3) Immutables objects (String, Date)
4) The "one" side of a relationship
5) The "many" side of a relationship
6) An arbitrary object
The overhead of copying arguments is incurred only for types (5) and (6).
That is, types (1) - (4) do not need to be treated differently for local
vs. remote interfaces, since you can't tell the difference between getting
the EJBs instance, or a copy.
However, let's remember what we are trying to do. We are trying to model
fine-grained objects, typically in a relational database. As such, the
vast majority of our CMP fields (and therefore our argument values) will
be relatively simple data types. That is, if I am representing a row in
a database (as 99% of all fine-grained EBs would), then my fields would
typically be int, float, String, Date etc. I generally don't store
arbitrary Java objects in my database (case 6); it just ain't convenient.
So, the only really tricky case for argument passing is (5): passing the
Collection objects which correspond to the "many" side of a relationship.
Clearly, there are problems with passing these types, and distinguishing
between pass-by-reference and pass-by-value semantics for client interaction
with these Collections. There absolutely are problems here, which I won't
go into. However, I do feel (and have for quite some time) that it might
have been better to try to solve this one problem (case 5), than have to
introduce a brand new programming model into EJB 2.0 (local interfaces).
In fact, in our current implementation of local interfaces, we are simply
reusing the same machinery that we already use for remote interfaces. That
is, we have spent quite some time making our colocated remote interface
access extremely fast: by avoiding argument copying where not needed (cases
1-4), by skipping over transaction and security checks where not needed,
implementing find/load optimizations, implementing optimistic concurrency,
etc. All of this optimization work that has already been done to give our
EJB 1.1 product high-speed, fine-grained access to EBs, is being be leveraged
for the same purpose in EJB 2.0. Really, the only thing that really makes
things faster in EJB 2.0 is the introduction of the getter/setter model for
EBs, which does allow lazy loading to be done efficiently without resorting
to post-processing (which I don't like).
In short, there are two arguments for the introduction of local interfaces:
1) It allows EJBs to run faster.
2) It simplifies the programming model, by making it clear where pass-by-
reference happens, vs. pass-by-value.
I would argue that only (2) is valid. All of the perceived performance
"benefits" of EJB 2.0 were possible in EJB 1.1. The only real difference
is in the standardization of PbV vs. PbR, and even here I don't believe
this has a significant performance impact. (For example, we run the ECperf
performance benchmark with PbV and PbR. The performance difference is less
than 3%.)
-jkw
Richard Monson-Haefel wrote:
> Hello All,
>
> In the past we have pushed the concept of coarse-grained entity beans
> because of the overhead of making fine-grained beans available over the
> network and the assumed performance penalties associated with
> fine-grained data access in light of managing concurrency, identity,
> security and transactions.
>
> I believe, however, that the new EJB 2.0 CMP programming model with
> local interfaces will allow us to move to a much more granular model for
> entity beans than we have advocated in the past. As I have been working
> on implementing an EJB container system, I have yet to find any real
> technical challenges to allow entity beans to be very granular. It
> seems reasonable, for example, to allow entity beans to be as granular
> as Addresses or Phone numbers. This flys directly in the face of past
> recommendations by others and myself in particular.
>
> The reason this is possible in EJB 2.0 CMP (I'm not talking about BMP )
> is that the abstract programming model now makes it possible for the
> container to use more performant mechanisms to mange persistence. For
> example, lazy loading and optimistic locking strategies can be
> implemented without a problem. For relational databases, all you need
> is a decent OR mapping facility. For OODBMS (pretty rare in actual
> deployments) the fit is even more natural. With CMP over ERP you have
> develop the beans with the ERP system foremost in your mind. Of course
> this is true of any backbend, but more so with ERP systems. So
> fine-grained entity beans may not be possible here.
>
> The new abstract persistence model allows vendors to optimize database
> access and supports a finer grained component model. The introduction of
> local interfaces restrict the use of the bean within the same JVM and
> enforce semantics of pass by reference as opposed to value (we could do
> it before but now its official) and this seems to further improve
> performance and allow for more granularity.
>
> Anyway, It would be interesting to hear how vendors are dealing with
> this and if they agree that fine grained entity beans are not only
> desirable but practical. Conjecture from everyone else is also welcome,
> but I think the vendors have a unique perspective on this since they are
> the ones doing the actual implementation.
>
> NOTE: There is room for improvement such as restricting the transaction
> security attributes of local interface, which I cover in another e-mail.
>
> Richard
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.jMiddleware.com
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
