File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes why entity bean cannot manage own transtaction while session beans can do this ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "why entity bean cannot manage own transtaction while session beans can do this ?" Watch "why entity bean cannot manage own transtaction while session beans can do this ?" New topic
Author

why entity bean cannot manage own transtaction while session beans can do this ?

giuseppe astarita
Greenhorn

Joined: Nov 10, 2005
Posts: 11
Entity bean can never access EJBContext.getUsertTransction() while session can access this method: why ?

Thank you for answer
Scott Selikoff
author
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3716
    
    5

From the API:

Only enterprise beans with bean-managed transactions are allowed to to use the UserTransaction interface. As entity beans must always use container-managed transactions, only session beans or message-driven beans with bean-managed transactions are allowed to invoke this method.


My Blog: Down Home Country Coding with Scott Selikoff
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Well, let's try to address the "Why" of this question. Entity bean interfaces represent individual accesses to attributes, right? So in what context would it use a user transaction? If you tried to use a user transaction in an accessor-type method then that means that EVERY attribute access would have to be its own transaction. That would be horribly, terribly inefficient -- if you had a simple Address EJB then getting all it's attributes would amount to four or five separate transactions!

That's why transaction control has to occur outside the Entity bean, in either the container or in a controlling Session bean -- to create a transaction that has a more meaningful scope.

Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Giuseppe,

The actual reason is little bit more subtle and relies upon the way the container should mange the transactions. As per EJB specs entity beans follow a load-and-store cycle for each transaction. This means that the container calls ejbLoad before the transaction begins and ejbStore just before committing the transaction (this will ensure that the bean and the database are always in sync). If you�d be allowed to write BMT then you�d obviously write code to perform begin and commit. Because of the load-and-store cycle it makes sense to start the transaction in ejbLoad and commit it in ejbStore. The problem is that you don�t call those methods directly. They are callback methods and are always invoked by the container. Neither you nor the bean can enforce that these two methods to be called in this order; they actually might not be called at all. It is very possible that only ejbLoad would be called and if you�d start the transaction here it will never commit.
The reason above it�s actually Sun�s official standpoint and it should be more than enough to clarify your doubt. However there is another one that I personally always considered it being pretty good too. It is related to the fact that entity EJBs (unlike session EJBs) are re-entrant. Basically with entity EJBs, a scenario like this is possible:

If you�d start the transaction in A, then you�d have to start another one again (inside of the first tx), after B calls A. This would basically imply that your system would have to use nested transactions as well. On the other hand, J2EE doesn�t support nested transactions either.
Regards.


I think, therefore I exist -- Rene Descartes
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: why entity bean cannot manage own transtaction while session beans can do this ?