Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

EJB restrictions for transactions.  RSS feed

 
Abhinav Srivastava
Ranch Hand
Posts: 354
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Purushoth Thambu
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Abhinav Srivastava
Ranch Hand
Posts: 354
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Purushoth Thambu
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Abhinav Srivastava
Ranch Hand
Posts: 354
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Abhinav Srivastava
Ranch Hand
Posts: 354
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!