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.
Paul: It always comes down to the basics: the business logic you are using to implement the business requirements of the application, and partly how you are implementing it. For example consider the situation where a transaction is implemented in more than one methods :-). In other words, you have a method that does something which is always a part of a transaction (that has already started) and never a full transaction by itself. Mandatory is the only option you have.
Exercise: Think of an example :-). Hint: Transactions often have more than one steps. (I guess the teacher inside is taking over me). Thank you for a very good and thoughtful question, Paul.
Originally posted by Paul Croarkin: Of the six EJB transaction types (Required, RequiresNew, Supports, NotSupported, Mandatory, Never), Required and RequiresNew seem pretty easy to understand, but some of the others are not so clear.
Supports seems to equate to "I don't care" and could be dangerous.
NotSupported and Never also seem like they should be avoided. Would it really hurt to use Required on RequiresNew instead?
Couldn't you use RequiresNew anywhere that you would use Mandatory and avoid the possibility of throwing a TransactionRequiredException?
[ July 28, 2005: Message edited by: Paul Sanghera ]
Paul Sanghera, Ph.D.<br />SCBCD, SCJP, Project+, Network+, Linux+, CNA.