This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes State Full Sesion Beans & Transactions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "State Full Sesion Beans & Transactions" Watch "State Full Sesion Beans & Transactions" New topic
Author

State Full Sesion Beans & Transactions

Nehal Dave
Greenhorn

Joined: Dec 22, 2000
Posts: 28
I have a confusion about transactions with statefull session beans. If i use delarative transaction does all the methods of the bean in which ever called is a single transaction???
Am totally LOST......
Christian Ebage
Ranch Hand

Joined: Aug 29, 2002
Posts: 47
It very much depends on how you configure it in
your deployment descriptor.
1) If you use the required attribute, this means
that the method in question will be called by
the container in a transaction context,
regardless the client was involved in
transaction or not.
2) If you use the requires new attribute, the
container always starts a new transaction, when
invoking this method.
3) if you use the not supported attribute,the
method cannot be called by the container in a
transaction context.This means if a client
involed in a transaction calls this method,
the container suspends the transaction before
calling that method.
4) If you use the supports attribute, it means
the container does not have to suspend
any transaction before calling this method.
If a calling method is not involved in a
transaction, the container does not have to
start a new transaction.
5) The mandatory attribute means any client
calling this method must be involved in
transaction before calling this
method.Otherwise the container will throw
an Exception.
6) The never attribute means that bean
is not expecting a transaction. If a client
calls this bean in a transaction, the container
throws an exception, othewise the container
simply invokes this method.
Ebage
SCJP
SCEA
[ December 10, 2002: Message edited by: Christian Ebage ]
[ December 10, 2002: Message edited by: Christian Ebage ]
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Nehal,
Assuming CMT, then the functionality of your transaction will depend largely on your configuration. A transaction can span multiple method calls, or it could span none.
Since Christian responded to you with a description of each type of declarative transaction attribute, I won't repeat that here. I will however give you a simple example to try and demonstrate.
Here is the situation:
We have an EJB (doesn't matter what type) with three methods: A, B, C. Method A calls method B, method B calls method C. Therefore the chain is A->B->C. Pretty simple right? Let's look at a couple different scenarios.
Scenario 1:
Method A is marked as Required
Method B is marked as Required
Method C is marked as Supports
Scenario 1 Breakdown:
Method A is called.
Container creates a new transaction if one is not in progress.
Method B is called and joins the current transaction.
Method C is called and also joins the current transaction.
Method C returns.
Method B returns.
Method A returns.
Container commits or rollsback the transaction.
Scenario 1 Analysis:
All three method calls happened within the context of the same transaction. Had any one of them decided to rollback, then any work done on transactional resources by the other two would also be rolled back.
Scenario 2:
Method A is marked as Required
Method B is marked as RequiresNew
Method C is marked as NotSupported
Scenario 1 Breakdown:
Method A is called.
Container creates a new transaction if one is not in progress.
Method B is called.
Container creates a new transaction and temporarily blocks Method A's transaction.
Method C is called which executes outside the context of any transaction.
Method C returns.
Method B returns.
Container commits or rollsback B's transaction.
Method A returns.
Container commits or rollsback A's transaction.
Scenario 2 Analysis:
All three method calls happened within the different transactional contexts (or in the case of C, no transactional context). Had any one of them decided to rollback, then the work done by the other two would not have been affected.
The important thing to note here, is that the only difference between the two scenarios was the transactional attributes that were set on the ejb. Thus it is easy to see how powerful declarative transactioning can be in terms of developer productivity.
Does that answer your question?
Nehal Dave
Greenhorn

Joined: Dec 22, 2000
Posts: 28
Christian & Chris
Thanks for ur replies. It really made my understanding clear. What i understood is that the scope of tranaction is limited to a method.
Correct me if i am wrong.
Cheers
Nehal.
 
 
subject: State Full Sesion Beans & Transactions