Win a copy of Mastering Corda: Blockchain for Java Developers this week in the Cloud/Virtualization 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 ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
  • salvin francis
  • Frits Walraven
  • Piet Souris

Exception in enterprise bean

Ranch Hand
Posts: 582
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,
I am confuse about exception in enterprise bean.
According to ejb 2.0 specification...
An application exception class must not be defined as a subclass of the java.lang.RuntimeException or of the java.rmi.RemoteException.
In my projects, I always make my application exceptions extends RuntimeException. Because of that, I am sure that all my transactions will be rollbacked by Container.
Do it harm my overall application processes?
What are the main differences between extends RuntimeException and extends Exception?
Correct me if I am wrong....
Cowgirl and Author
Posts: 1589
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The exception model for EJB is that Application exceptions (which must NOT be runtime exceptions, or remote exceptions) are those that the client is expecting, and can possibly recover from. They MUST be declared in your client interfaces, and of course the compiler will keep everyone honest about that because they will be checked exceptions. The idea is that transaction rollback should NOT always be automatic, and that you should have the ability to separate exceptions from bean destruction.
So, if you are running code and find that things have gone horribly wrong, and the bean is possibly corrupt, and of course the transaction must rollback, then throw an EJBException (system exception).
BUT... if things go wrong in a way that didn't necessarily ruin the transaction or the bean itself, so you don't want to kill the bean, then throw an application exception (one of the standard EJB application exceptions: CreateException, RemoveException, ObjectNotFoundException, FinderException, DuplicateKeyException) or else one that you have created by extending something that is NOT RuntimeException or RemoteException.
BUT... many times (perhaps MOST times) even with an application exception you WILL find that you need to rollback the exception (it sounds like that is the problem you are trying to solve). And in that case, the EJB model wants you to go ahead and throw the application exception, but BEFORE you do, call setRollbackOnly() on your context. This will guarantee that the transaction will not commit, while still giving the client a chance to recover without destroying the bean.
Remember, ANY RuntimeException (meaning: non-application exception) will ALWAYS destroy the bean. And bean destruction is not guaranteed to be transparent to the client, EVEN with entity beans.
Does this help? Hey, I just realized that I know a book that has a whole chapter on this...
Fisher Daniel
Ranch Hand
Posts: 582
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Kathy for your excellent explanation.
Now, I know what I should do with me enterprise bean....
I have question again about this....
What the differences between i use a code to rollback transaction and using trans-attribute in ejb-jar.xml ?
Hmm... what is the title a book that has a whole chapter on this?
Is it your book, Head First EJB?
[ October 28, 2003: Message edited by: Fisher Daniel ]
It will give me the powers of the gods. Not bad for a tiny ad:
the value of filler advertising in 2020
    Bookmark Topic Watch Topic
  • New Topic