• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

Transaction boundries in CMT

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Cowgirl and Author
Posts: 1589
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
keep an eye out for scorpions and black widows. But the tiny ads are safe.
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic