The theory certainly seems to suggest that there is the ejb coder and the ejb deployer, and that neither one should have to do much with the other. If bean A calls bean B, a deployer can choose to have bean B be Required or RequiresNew at deployment time. However, in reality, the choice has a lot to do with how bean A is coded, doesn't it? In other words, bean B throws EJBException on error, causing the transaction to roll back. If the deployer has set B to Required and A continues merrily it's a problem, since the transaction that A was in is now rolled back. If the deployer sets B to RequiresNew and A continues merrily, no problem. If this is true, what's a bean coder to do if he doesn't know the intended transaction semantics ahead of time? Conversely, if he does know the intended transaction semantics, what's a bean deployer to do? Am I thinking about this wrong? I've been grappling with this issue for a while.
Thanks Eric Kaplan Armanta, Inc. 55 Madison Ave. Morristown, NJ 07960 Phone: (973) 326-9600
winmail.dat
Description: application/ms-tnef
