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.
(2) is wrong since the DB is in indeterministic state because of the data changes done using the prior business method call which should have either been rolled back or committed before the client makes a safe business method call again.
SCJP, SCJD, SCWCD, SCBCD, SCEA
Joined: Feb 06, 2001
Ravindra, it sounds good
Joined: Jan 04, 2001
Instead of The client can safely continue the transaction by retrying the operation if an application exception is received, but only after checking the transaction has not been marked for rollback.
If the statement would have been The client can safely continue the transaction by handling the exception and retrying the operation if an application exception is received, but only after checking the transaction has not been marked for rollback.
The EJB specification for exception handling is designed to meet these high-level goals: � An application exception thrown by an enterprise bean instance should be reported to the client precisely (i.e., the client gets the same exception). � An application exception thrown by an enterprise bean instance should not automatically rollback a client�s transaction. The client should typically be given a chance to recover a transaction from an application exception. � An unexpected exception that may have left the instance�s state variables and/or underlying persistent data in an inconsistent state can be handled safely.
-- Ravi [ March 27, 2005: Message edited by: ravindra janapareddy ]
SCEA, SCBCD, SCWCD, SCJD, SCJP
Joined: Nov 04, 2000
I want to revise my previously statement that (2) is "wrong" to (2) is "right" and this is because while reading EJB specs, I have come across this:
If a client program receives an app exception from an EJB invocation while the client is associated with a tx, the client can typically continue the tx because an app exception does not automatically cause the container to mark the tx for rollback.
Although the container does not automatically mark for rollback a tx because of a thrown app exception, the tx might have been marked for rollback by the EJB instance before it threw the app exception.
There are two ways to learn if a particular app exception results in tx rollback or not: � Statically. Programmers can check the docs of the EJB�s home or component interface. The Bean Provider may have specified the app exceptions for which the EJB marks the tx for rollback before throwing the exception. � Dynamically. Clients that are EJB with container-managed transaction demarcation can use the getRollbackOnly method of the javax.ejb.EJBContext object to learn if the current tx has been marked for rollback; other clients may use the get-Status method of the javax.transaction.UserTransaction interface to obtain the tx status.
-- Ravi [ March 28, 2005: Message edited by: Ravindra Janapareddy ]
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