A session bean instance can participate in at most a single transaction at a time. If a session bean instance is participating in a transaction, it is an error for a client to invoke a method on the session object such that the transaction attribute in the deployment descriptor would cause the container to execute the method in a different transaction context
If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before invoking the enterprise bean�s business method. The container resumes the suspended association when the business method has completed.
So Suspended or Exception! Though I have understood the later, I am not able to visualise the scenario for the first case. Can anyone throw some light here...
We are talking two different things here. Consider this
A) Error scenario - Client creates a SFSB (assume instance sf1) - Client starts a transaction (RequiresNew) by invoking sf1.method1 - Assume transaction spans multiple methods (eg commit happens on sf1.method4) - After method1 client invokes sf1.method2 which is configured to start a new transaction (RequiresNew) - This is form of nested transactions
This is an error situation. You cannot start two transactions on the SAME SFSB. If EJB spec had allowed this to happen it would have been difficult/complex to restore the state of the bean if rollback happens.
B) Suspend incoming transaction
- Client creates a new instances of SFSB1 and SFSB2 - Method1 in SFSB1 and Method5 in SFSB2 has transaction attributes (RequiresNew) - Client invokes SFSB1.Method1 and starts the transaction. This transaction is not committed here but assume in some Method2 - Now client invokes SFSB2.Method5 which also requires new transaction.
In this situation EJB container should suspend the SFSB1 transaction.
thanks. though it seems like it can only happen if the transaction is bean managed or say we have a multi-threaded client with each thread acting on the same bean.
The later part "multi threaded clients on single object" is perfect however the exception will be generated only in container managed SFSB. If SFSB is bean managed it's coders responsibility.
in container managed sfsb, how can the transaction span across multiple methods i.e. start in sf1.method1 and end in sf1.method4 ??? [ August 10, 2007: Message edited by: Abhinav Srivastava ]
however the exception will be generated only in container managed SFSB
I think it will be generated for BMTs too
in container managed sfsb, how can the transaction span across multiple methods i.e. start in sf1.method1 and end in sf1.method4 ???
I see where you are coming from - the scope of a CMT is a method, right? Its only when you use BM within a SFSB that you could have transactions spanning multiple methods (which I personally believe is not such a great idea). However just consider the following
1. A client starts an UserTransaction (say from within a Servlet) and then creates 2 threads each accessing the same ejb (the ejb methods are CMTs with the 'supports' attribute.
2. Even in the vanilla approach (where transaction is started in the ejbs - CMT) , two threads acting on the same object can access the same method at the same time causing an error. In the example you have discussed, what if method4 calls method1 in it's implementation?
3. Finally if we are speaking about multiple threads of invocation, shouldn't we include Stateless SB too?
Well, again concurrent call is the only scenario for this exception. In case of SLSB, I am inclined towards saying that container can assign a different sb to each thread so this situation should never occur.