Hi guys,
This is what the
EJB 3.0 spec says about stateful bean instances (CMT-based, implementing SessionSynchronization) which are present in the "Transaction Method-Ready" state from their life cycle:
Session bean methods invoked by the client in this transaction can now be delegated to the
bean instance. An error occurs if a client attempts to invoke a method on the session object and
the 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 really cannot understand how this could happen! Stateful bean instances are dedicated to particular client, and EJB calls are synchronous, so the client code should look like:
0. acquire stateful bean instance - bean (no matter how exactly)
1. bean.method1();
2. bean.method2();
...
n. bean.methodN();
(n+1). bean.removeMethod(); or nothing (in which case the session will expire at some moment)
So, if method1() requires the beginning of a new CMT transaction - T1, it will be created by the JTA manager at the method beginning (and afterBegin() will be called on the bean instance). From now on, the bean instance is in "Transaction Method-Ready" state from its complete life cycle, associated with T1.
But before the 'bad' method2() could be executed from the client (that requires a new transactional context via, for instance, a REQUIRES_NEW attribute), method1() should be completed! This means that T1 should have been committed/rolled back. It should be a history! And i cannot see any way that the client could make so that new transactional context is required,
while T1 is still active and associated with the bean instance . Stateful bean instances simply cannot be shared among different clients.
Any help would be appreciated! I am having my SCBCD 5 exam in 5 days ;)
The only option left to reproduce the scenario from the spec, is the one in which: after the method1() has started and the bean instance is associated with T1, inside the method1() source code, the bean itself invokes some other business method from the bean class (that requires new transactional context). But this is not relevant, since here there is no
client interaction: the
bean is doing this itself!
Can someone reproduce the scenario from the spec quote correctly ?
