Forums Register Login

EJB restrictions for transactions.

+Pie Number of slices to send: Send
EJB 2.1 Specs

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...

thanks.
+Pie Number of slices to send: Send
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.

Hope it make sense.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
 


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?

cheers,
ram.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 


Well, again concurrent call is the only scenario for this exception.



Agreed, but how about point #2 in my previous reply?


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.



Well, I think (& hope) so too - unless someone (server implementation) decided to optimize early

cheers,
ram.
You are HERE! The other map is obviously wrong. Better confirm with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 818 times.
Similar Threads
BMT not propogated to invoked beans
doubt in ejb transaction
Transaction Question from spec
need clarification on transaction
Regarding Tx and Security Context for Interceptor method
query on bean managed transaction from ejb3.1 specs ?
Transaction propagation - REQUIRES_NEW
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 05:18:10.