> 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.
And comment:
> [JP] Wrong... ejbStore is called only once (or at least, in most app servers
You would have to start the transaction in the session bean I
believe. Otherwise, even with "required", your transaction will end
when you finish the call. Although maybe you can set up some TX
attribute on the session bean itself so it maintains the context.
Hmm.. Can't rememeber now.
I think the second approach is what designers intended, with you
starting the transaction in the session bean which has information
from a number of places.
Otherwise, the third way saves you not just storing but loading (as
for every getX() the ejbLoad is called - of course, with Orion (and
Weblogic I believe) you can say this server is the only one that
accesses the db so it doesn't do it, but this goes out of the window
once you start clustering etc.. Plus, some of the AS out there don't
support it).
What you can do, is to code something like "setFromBean(),
getBean()" methods which use reflection for setting/getting so you
don't have to maintain these methods. Of course, you still have to
maintain both EJB and the bean (what you call bulk accessor) as
unfortunately you can't add attributes on the fly in Java. OTOH,
the get/set method can warn you what you've forgotten where, so
it's not that bad.
Regards,
VF
Thought for the day:
Old programmers never die; they just branch to a new address.
