Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

TransactionRolledback Exception

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
 
author
Posts: 4173
29
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Samuel Lima
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Posts: 4173
29
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
    Bookmark Topic Watch Topic
  • New Topic