Hi,
I have a question regarding exception handling within container
managed transactions in WAS 4.0 AE. In our application we have a number of places
where we catch checked exceptions (such as SQLException) and rethrow
them wrapped in EJBExceptions in a text book manner. We have a set off
checked exception classes which allow a few nice bits of functionality
such as maintaining stack traces across RMI boundaries and logging
which we find useful in debugging and passing error messages back to
clients.
However, we now have a requirement to run our application within a
transactional context. What we have found is if we throw an unchecked
exception (such as an EJBException) from an EJB method within a
container initiated transaction then the client of that method
receives a javax.ejb.TransactionRolledBackException as we would
expect. However, rather than wrapping the exception which was thrown
from the EJB, it wraps an instance of
org.omg.CORBA.TRANSACTION_ROLLEDBACK and any error messages or stack
trace from the actual exception thrown is lost.
I have read in a thread on an IBM news group that the reason for this is
compliance with the RMI-IIOP spec. My questions are:
1) Is there any way to have context information (error messages,
statck trace) included in this presumably container generated Corba
exception?
2) What are the advantages of using unchecked exceptions to signal to
the contaniner to roll back a transaction rather than a bean
explicitly call setRollBackOnly and then throw a checked exception?
Any help or advice in this area would be much appreciated
Cheers
Dave Coombes
[email protected]