error in running in a different transaction context in stateful bean ?

[Himai Minh]

On p. 90 of JSR-318, the second to last bullet says this :

An error occurs if a client (of a stateful bean) attempts to invoke a method on the session object and the stateful bean's metadata annotations and/or deployment descriptor for the method requires that the container
invoke the method in a different transaction context than the one with which the instance is currently associated or in an unspecified transaction context.

I don't understand why there is an occur when a stateful bean's method is run within a different transaction context than the current one.

To my understanding,
1. if the transaction management attribute is REQUIRES_NEW, the method starts a new transaction and suspends the current transaction.
2. Or, if the attribute is NOT_SUPPORT, the method runs in an unspecified transaction context and suspends the current transaction.
3. Or, if the attribute is NEVER, the method will throw an exception because there is a current transaction running.

An error occurs only in case 3.

Any comments?

[Frits Walraven]

At that part of the specifications you are in the context of the diagram on page 89 in the state "Method Ready In Transaction". This effectively means that the container has started a transaction for the stateful bean (for that specific client) and waits for a method to be invoked.

If at this point a method is invoked with a different transaction context than the one that the container started (in other words: in a different tx-context or with no tx-context) there is something wrong (because the client is always associated with the same stateful bean instance).

[Himai Minh]

Hi Frits. Thanks for your explanation.
1. Does it mean a REQUIRES_NEW is specified for the method when it is invoked in a different transaction context?
2. Does it mean a NOT_SUPPORT is specified for the method when it is invoked in a non-transactional context?
3. Or, case 1 or 2 do not apply in this case . Does it mean the method is invoked in transaction B while the container has just started a transaction A for it to run?

[Frits Walraven]

The lifecycle diagram describes the two possible scenarios

Container Managed Stateful Session Bean

Bean Managed Stateful Session Bean

For a CM Stateful Session Bean we know that every method, by default, runs in a container started transaction, and this transaction commits as soon as the method ends. It will go from the "Method Ready" state to "Method Ready in Transaction" and back to the "Method Ready" state. The only case it would be possible to execute in another transaction context (or no transaction context) would be when there is a loopback call (check 2.1.12 Loopback call (re-entry) of my notes) however this is not allowed (an IllegalLoopbackException is thrown).

For a BM Stateful Session Bean it is a different situation as you can start a transaction in one method and commit the transaction in another method. The @TransactionAttribute annotations do not apply in this case. The client can make multiple calls to the Stateful Session Bean before the transaction commits, however this will always be in the same transaction context of the transaction that you started (as you already noted: client transactions will be suspended). I can't think of a possible scenario where this could go wrong, because even a loopback call wouldn't cause the bean to get a different transaction context (because the transaction started on the other bean would be suspended).

Does this clarify things?

[Himai Minh]

Hi Frits. Thanks so much for the clarification. The explanation is much clearer than the reference materials.

The reference materials just simply says there is no nested transaction and your explanation elaborate this point for both CMT and BMT.

From the J2EE tutorial, http://docs.oracle.com/javaee/5/tutorial/doc/bncij.html , Figure 33-1 describes how the transaction management attributes work.
So, does it mean figure 33-1 does not apply to the following scenarios:
1. if it is CMT, a stateful bean instance 1 cannot execute its transaction TX2 within TX1 of the same bean instance via SessionBeanContext().getBusinessObject() (this is a loopback call refer to your notes p.18)? Not possible at all.
2. if it is BMT, stateful bean instance 2's TX2 will suspend TX1.

However, Figure 33-1 may apply to this:
if it is CMT, a stateful bean instance 1 can execute its transaction TX2 within TX1 of a different instance of the same bean class, say instance 2 (avoid reentrancy) (idea is the same as stateless bean on p.18)
?


It really seems to me that Figure 33-1 will only apply to MDB, stateless bean ,singleton bean and stateful bean (but two different instances of this bean). But this tutorial does not say so.

[Frits Walraven]

However, Figure 33-1 may apply to this:
if it is CMT, a stateful bean instance 1 can execute its transaction TX2 within TX1 of a different instance of the same bean class, say instance 2 (avoid reentrancy) (idea is the same as stateless bean on p.18) ?

Be careful with the wording transaction TX2 within TX1. Transactions are never run inside each other: TX? of Bean-2 (figure 33-1) is either TX1 (method-B runs inside the same transaction context) or TX2 (method-B runs in a new transaction context and TX1 is suspended by the container).

Coming back to your question: if Bean-1 and Bean-2 are two different stateful session bean instances it is possible that method-A runs in TX1 and method-B runs in TX2, but never inside each other! However note that this is a theoretical discussion as I can't think of any application that has two stateful session beans for the same client and calling methods on each other (very bad design).

It really seems to me that Figure 33-1 will only apply to MDB, stateless bean ,singleton bean and stateful bean (but two different instances of this bean). But this tutorial does not say so.

I agree with that they could have made that clearer: Bean-1 and Bean-2 are two different instances, but also have two different implementations (i.e. there is no method-A on Bean-2). Last time I found something questionable in the EE6 tutorial I reported that via their feedback page and they changed it.