> "When asked about this, one WebLogic consultant's response was "all the
> systems I've seen have used only
> Stateless SBs with JDBC", hence my concern. Guidnace on this is welcome."
>
> Is WebLogic replicating these guys. I am sure I have met this consultant
on
> my travels. Maybe just some pooled instance. Please someone call
ejbRemove.
It's pretty easy to argue that none of the EJB containers out there is
really ready for prime time when it comes to CMP. There are just flaws in
the EJB 1.1 spec (2.0 will surely fix a few of them) that cause more reads
than necessary, make it hard for objects to span multiple tables, make
updates to objects more frequent than necessary, require public attributes,
often confuse programmers into designing entity beans to be mirrors of their
SQL tables instead of objects, complicate the clear needs of main
independent business objects to have relationships to many dependent objects
which also need to persist, etc. Heck, the whole "primary key" concept is
lame in an OO world where OID/UID/GUIDs have reigned and would clearly make
sense if using an object database instead of a relational db.
Because of these things, when I use EJB, I also generally stick to stateless
session beans and use JDBC or other schemes to get at the data. It's not as
elegant as the promise of EJB, but it's where the state of EJB currently is.
In fact, this is really the main transaction model used by non-EJB servers
like Tandem Pathway and IBM CICS. The benefits are pretty clear at this
point: a) by being stateless session beans, the beans are not instantiated
and destroyed repeatedly and can be shared by an unlimited number of
concurrent users which is critical for large scale systems, in particular
successful web apps; b) by doing your own JDBC, you can optimize the way
objects are loaded, unloaded, saved, updated, etc.
For example, often when doing an update on an object, you really only are
changing a state attribute or something minor. There's no need to update
the entire object's attributes, only that one attribute (SQL: UPDATE UserTbl
SET visit_count=visit_count+1). This is true also for objects that are not
only big by themselves, but perhaps have a list of dependent objects that
load with it. Using CMP makes this nearly impossible to get right with the
containers I've seen, many having proprietary hooks like "dirty" flags to
help the CMP know what to do.
Entity beans also seem to suffer from trying to return a list of objects,
such as after a search, which is quite typical of every app I've written.
By having entity beans, it's a pain to return a collection of such remote
objects to have the client then loop through them doing remote calls on
each. The fact of the matter is, distributed systems need to pass large
numbers of objects around, and having clients then do all remote calls on
these objects is quite expensive and slow. More often, people return simple
beans/objects in their collections, letting the client update at will, and
then return the updated beans back to the "repository stateless session
bean" for optimistic locking-style updates to the persistent store.
BMP is very much the same as stateless session beans doing JDBC, but you
still get problems related to remote invocations of collections of objects
and the unnecessary overhead of calls to ejbStore(), etc. when it's not
necessarily appropriate.
I think EJBs are wonderful, but no 3 year old technology can be robust yet,
especially when it needs to serve so many existing TP systems.
David
===========================================================================
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".
