This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question about Transactions in EJB / MDB scenario

 
Kai Wähner
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have got the following question about EJB 2.1 concerning Container- and Bean-managed transactions (CMT / BMT). We use WAS 6.1 for deployment and Oracle 10g as database, but I assume this does not matter...

-----------------------------------------------------------------------------------------------
Here is the scenario:

A MDB (Container-managed + transaction required specified) receives a message from a queue and then calls an operation of a Stateless EJB (bean-managed + requires new transaction specified). The MDB got the EJB through a JNDI lookup.

The Stateless EJB does this within the called operation:

myEJBSessionContext.getUserTransaction.begin();
doSomething...
myEJBSessionContext.getUserTransaction.commit();
return xyz;

The MDB receives the return value, does some more logic and finishes (then the MDB-transaction is committed through the container).

-----------------------------------------------------------------------------------------------


Is the above scenario legal regarding the EJB specifiation, or does the following rule apply (copied from a blog). Two possible explanations:

1) The scenario is illegal to use javax.transaction.UserTransaction in CMT ejb and the Container will throw java.lang.IllegalStateException if this is the case. javax.transaction.UserTransaction can be only used for BMT ejb (<transaction-type>Bean</transaction-type>).

OR:

2) The scenario is legal because a new EJB is created, and "requires new" suspends the transaction from the MDB while the Stateless EJB is used without Container-managed transactions. After finishing the Statelesss EJB and returning the value, the suspended MDB-transaction is re-activated.


Please help me and explain your answer. Thank you a lot...

Greetings Kai
 
Deepak Pant
Ranch Hand
Posts: 446
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think your point #2 is absolutely correct. The MDB-EJB interaction is true even for EJB-EJB scenario as well.

Since MDB has required and EJB has requires new the transaction context will not propagate from MDB to EJB. Both MDB and EJB can chose to be either container managed or bean managed.
 
Jonh Smith
Ranch Hand
Posts: 39
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I understood your point #1 would actualy be the correct answer.

The spec says about this:

17.6.2.10 Handling of getUserTransaction Method
If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke
the getUserTransaction method of the EJBContext interface, the container must throw the
java.lang.IllegalStateException.
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jonh Smith wrote:If I understood your point #1 would actualy be the correct answer.

The spec says about this:

17.6.2.10 Handling of getUserTransaction Method
If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke
the getUserTransaction method of the EJBContext interface, the container must throw the
java.lang.IllegalStateException.


That's right. But the getUserTransaction() method is being invoked by the bean with a BMT as per the original post. I agree with #2.

Ram.
 
Jonh Smith
Ranch Hand
Posts: 39
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yep. if it is indeed BMT, #2 is correct, but then "bean-managed + requires new transaction specified" makes no sense as it is saying the bean is (BMT+CMT). so basicaly, if the bean is BMT #2 is correct. if it is CMT, #1 is correct.
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that was very sharp and perceptive. I missed that

ram.
 
Deepak Pant
Ranch Hand
Posts: 446
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think John makes an excellent point.
The transaction attribute applies only to CMT. It has no bearing on BMT. As per EJB 3.0 final spec:

1. With bean-managed transaction demarcation, the enterprise bean code demarcates transactions using the javax.transaction.UserTransaction interface.

2. With container-managed transaction demarcation, the container demarcates transactions per instructions provided by the developer in metadata annotations or in the deployment descriptor. These instructions, called transaction attributes, tell the container whether it should include the work performed by an enterprise bean method in a client’s transaction, run the enterprise bean method in a new transaction started by the container, or run the method with “no transaction” (Refer to Subsection 13.6.5 for the description of the “no transaction” case).


The URL for the spec is:
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=ejb-3_0-fr-eval-oth-JSpec@CDS-CDS_JCP

 
Kai Wähner
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your replies. I now also think that #2 is correct.

The transaction attribute applies only to CMT. It has no bearing on BMT. As per EJB 3.0 final spec:


We use EJB 2.1, but there should be no difference. It really makes no sense to use this attribute if you use BMT ?!

Besides: I think it does not make sense in our scenario to use the BMT for the stateless bean, because if the BMT makes a rollback, then the container-managed MDB may succeed without a rollback although the stateless bean makes a rollback (and that should not happen in our application)...
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic