It depends on the context of the root exception. If the exception is
caused by a user error, or other condition that could be classified
as an application exception, I would go for option 1, in combination
with throwing an application exception (checked exception) as a
structured feedback to the client.
If the root exception is caused by an unexpected situation, like
inconsistent database content due to lacking validation logic in
other parts of the application, you should report a system exception,
i.e. go for option 2 (which discards the bean instance). In that
case, you could perfectly well just let the DataAccessException
(Spring runtime exception) go, without wrapping it in an ejb exception.
/Johan
7 nov 2005 kl. 00.34 skrev SUBSCRIBE EJB-INTEREST anonymous:
Hi,
I have a question.
I have a stateless session bean.
I want to rollback the transaction when an application exception
occured.
There are two options to do.Please let me know which one would be
better.
Option 1:
try{
//perform database operation}
catch(DataAccessException ex){
getSessionContext().setRollbackOnly()
}
Option 2:
try{
//perform database operation}
catch(DataAccessException ex){
throw new EJBException(ex);
}
======================================================================
=====
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
