aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes TransactionRolledback Exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "TransactionRolledback Exception" Watch "TransactionRolledback Exception" New topic
Author

TransactionRolledback Exception

Samuel Lima
Greenhorn

Joined: Sep 19, 2006
Posts: 7
"System exceptions are RuntimeExceptions, RemoteExceptions, and their subtypes. The

EJBException is subclass of the RuntimeException, so it's considered a system

exception.

System exceptions always cause a transaction to roll back when throw from a bean

method."

When a system exception is thrown by the bean method, it is caught by the conainer and

rethrown as a javax.transaction.TransactionRolledbackException.

The problem is: the client can�t catch the original exception that caused the

transaction to be rolled back.

The question is: How can the client get the original exception ?

Does anyone have a workaround for this problem ?

Thanks
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3704
    
    5

I would figure there would be something in the stack trace to tell you what went wrong, perhaps getLocalizedMessage() or getCause() would help?

Either way, I'm not sure what you are trying to do. System exceptions, to me, are only used when the EJB fails and cannot tell the client why it failed (such as general error message). If the server knows why/how the transaction failed, you should not throw an exception but instead pass a detailed message back to the client about why something failed.


My Blog: Down Home Country Coding with Scott Selikoff
Samuel Lima
Greenhorn

Joined: Sep 19, 2006
Posts: 7
Thanks for your reply.

When we have multitier applications it's diffilcult to couple with Exceptions, specially RuntimeExceptions.

EJB are located in different EAR's which have their own log files.

Within a cluster environment things get even more complicated for we have to determine which server attended the request and trace back the exception spanned along the machines.

In order to trace exceptions we have to follow all those logs and sometimes it gets confused.

I'd like to have the cause of the TransactionRolledbackException in the first layer.

I read the following articles, but it seems there is no way by the normal means.

So I'd like to know if there is at least a good practice to deal with this.

http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.support.was.doc/html/WebSphere_App

lication_Server/1081353.html

http://www.unix.org.ua/orelly/java-ent/ebeans/ch08_06.htm

Thanks,
Samuel
Samuel Lima
Greenhorn

Joined: Sep 19, 2006
Posts: 7
Forgot to say that (as it's described in the previos URL's I�ve sent) when applications are in different containers the root exception is not sent in the stack trace of the TransactionRolledbackException for it's a RMI/IOP (CORBA) limitation.

So we can't trust to find always the cause in the stace trace.

Thanks,
Samuel
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3704
    
    5

I'm trying to tell you, you shouldn't use exceptions for such detailed messaging (unless you create your own exception class). You should catch the exception on the server level and instead pass a detailed message object back to the client.
 
wood burning stoves
 
subject: TransactionRolledback Exception