-----Original Message-----
From: Smith, Bill (RIC) [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 28, 2000 10:44 AM
To: Orion-Interest
Subject: Maintaining Entity Beans
I'll start off with saying that this may be a little long winded, so bare
with me.
My question is in regards to entity beans, and their implementation in the
Orion container. Take the following scenario:
A client has a reference to an entity bean...let's say an address. The
client wants to update this address and calls the various setters for
updating the properties. In this case, each call to a setter would result in
a transaction and would result in two network hits per call, one to the
container, and one to the db. Ick, if you have a bunch of properties.
A second scenario is where you call a method in a session bean and pass it a
bulk accessor that resembles the entity bean and have the session bean
"copy" from the bulk accessor to the entity bean. In this way you at least
have everything contained in one transaction, but the session bean still
calls each setter which results in multiple db hits, even if they are only
committed at one time.
[JP] Wrong... ejbStore is called only once (or at least, in most app servers
with properly defined Tx attributes.
A third scenario is where the entity bean can receive the bulk accessor
itself, and updates the properties inside the entity bean. I speculate (but
haven't tried yet) that this would result in only a single call to ejbStore
for all the changes to the entity bean. The problem with this one is (same
in the previous) that you have to maintain two classes that are otherwise
the same, one for the entity bean, and one for the bulk accessor.
There are a number of other ways to skin this cat, bean managed
transactions, bean managed persistence, etc. But all these seem to move away
from some of the core benefits of the container.
I guess my question is this, what solutions have people come up with to
these problems or is it you just have to pick one and live with the pain?
How this relates to the Orion server is this. Weblogic offers a feature (I
can't remember the exact name) where (within a transaction) sets on an
entity bean can be deferred until the transaction is committed and done with
one db hit. Obviously, this doesn't solve all the problems. Does Orion have
any features like this? Are there any plans to offer such features?
If I'm missing some piece of information in this arena (I hope I am), please
fill me in.
TIA,
Bill
