This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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......
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 ]
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?
Joined: Dec 22, 2000
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.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com