Transaction boundries in CMT

[Scotty Brady]

Will a transaction ALWAYS commit or rollback at the end of a transactional unit--that is after a non-ejb client completes a call to an EJB method? From what I've read in HF and the spec I assume "yes." But I'm still left with that unsettling feeling that a transaction context can live after the method that created it is done. Some of this concern is because the spec doesn't make a clear distinction between ejb and non-ejb clients.
So, for example, does the 'Required' transaction attribute apply for non-ejb clients...can a method invoked by a non-ejb client attach itself to an transaction context. If so, where does it come from? Does it come from previous client call?
[ December 18, 2003: Message edited by: Scotty Brady ]

[Sunil Patil]

Hi Scott,
Transaction will always be either commited or rolled back at the end of the method call in case of CMT.
As per EJB Specs. 19.6.1 and 19.6.2 as client call to ejb will be using IIOP as wire protocol which is capable of carrying security and transaction information along with method call(Thats why in case of EJB IIOP is preferred over JRMP as wire protocol).
Now if you want you can lookup transaction service from JNDI in web or application client and start a transaction and then call EJB in that case ejb will participate in transaction which is allready started.
Sunil

[Kathy Sierra]

Howdy -- a transaction will NOT stay open at the end of the method that created the transaction, EXCEPT with a BMT stateFUL session bean. A stateFUL session bean using BMT is allowed to begin() a transaction in one method, and end it in some other method. But this is really really dangerous and probably stupid, because it could leave the transaction open... which means the bean can never be passivated!! (there's a picture in HFEJB about the clueless guy who doesn't care about stateful bean scalability and leaves his transactions open)
So, with a stateLESS bean, and any other CMT bean, the transaction will end when the method ends (or in the case of a BMT, when the bean ends the transaction programmatically, but it MUST occur before the end of the method).
But with a stateFUL bean, using BMT, a transaction can begin() in one method, but not rollback() or commit() even when the method ends.
Now, there IS a way in which a non bean client can actually start a transaction that propogates into the bean, but it is NOT required in the EJB spec that a container allow this. In the J2EE spec, however, it does specify that a J2EE server CAN choose to make a UserTransaction object available through JNDI to certain clients that the J2EE server is controlling, like a Servlet or even a "J2EE application client".
cheers,
Kathy