• 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 ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

ejbcertificate.com : Transactions : Question 5

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can somebody explain why Entity Beans can't use Bean Managed Transaction demarcation?
Thanks!
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The short, practical answer is ... because it makes your entity beans useless as a reusable component. Also, transaction management is best left to the application server - that's what they're there for.
It's all about atomic operations on your data. If an operation updates more than one entity then you want the whole thing to succeed or the whole thing to fail, nothing in between. If you put commits in the entity beans then it's very difficult to rollback if an error occurs at some point late in the operation.
Think of an account transfer which takes money from the first account and then pays it into a second account. If the paying in part fails how do you put the money back in the first account? What about if that then fails too?
The transaction should always "wrap" the entire operation. There are two obvious ways of achieving this in an EJB environment:
Use the javax.transaction package
Use a session bean to represent usecases and specify how transactions should be managed as part of the session bean's deployment descriptor.
Solution 2 is the "correct" way to do it. Either way, you can simply leave all transaction code out of your entity beans.
See link for the original message where i copied the answer above from...
 
Gayatri Aryan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeroen...I get it now!
But again, is it disallowed to use BMT demarcation at all or is it simply not a recommended way?
Thanks again.
[ April 01, 2004: Message edited by: Gayatri Aryan ]
 
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gayathri,
It is disallowed. The container calls ejbStore() and ejbLoad() and if you did a BMT you would need to call them explicitly. This is because typically a transaction exits between a ejbload() and store()(usually). Since the container only has the priviledge to call these methods and you dont have control over these it is ILLEGAL to have a BMT in a Entity Bean.

Prakash
[ April 01, 2004: Message edited by: Prakash Krishnamurthy ]
[ April 01, 2004: Message edited by: Prakash Krishnamurthy ]
 
Gayatri Aryan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Prakash. I've been reading about entity beans for almost about a week now...guess I couldn't put 2 and 2 together.
One more question - are Isolation Levels covered in the exam?
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gayatri Aryan:
One more question - are Isolation Levels covered in the exam?


No. Isolation levels are not covered in the exam.
Isolation levels are not mentioned in the Deployment descriptor xml.
They only exist at the database layer for the CMP entity beans.
 
You're not going crazy. You're going sane in a crazy word. Find comfort in this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic