Hi Richard,
I think one main issue that cause many to abstrain from fine-grained entity
beans and rely on course-grained eb's or direct jdbc session beans instead
is the inherent problem with finder + ejbLoad lazy loading. I was never too
enamored with this part of the spec. I believe that when a client
constructs and invokes a finder, 90% of the time the invoker intends to look
at all of the returned bean references. (If not, one can argue the client
should pick a better suited finder method!)
Now many vendors have already implemented toggle-able CMP 1.0 bulk-loading
after a finder invocation within the same txn. Certain vendors have also
added lazy or selective bulk-loading (field groups) for CMP 2.0. This is
also why I wrote up an analogous BMP pattern FatKeys:
http://www.theserverside.com/patterns/thread.jsp?thread_id=4540
so that BMP developers can have the same fun with bulk loading... But I
feel that optimized implementation, whether done by the vendor or the bean
developer, is still not enough. Perhaps a future spec needs to address
this issue, that the current ejbFind/ejbLoad model is awkward at best, and
turns people away from fine-grained entity beans.
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
Sent: Tuesday, May 08, 2001 8:38 AM
To: [EMAIL PROTECTED]
Subject: EJB 2.0 CMP: Entity bean granularity
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".
