This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Throwing EJBException from a Method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Throwing EJBException from a Method" Watch "Throwing EJBException from a Method" New topic
Author

Throwing EJBException from a Method

Ravi Kiran Va
Ranch Hand

Joined: Apr 18, 2009
Posts: 2234

Hi

I am working on EJB 2.1 application .
I have seen a method which is throwing a EJBException (I am working on a enhancement code which is already developed )
Is it neccessary to throw the RuntimeException (EJBException) in this case ??

What is the advantage one will get if we do so ??

Thanks in advance .



Save India From Corruption - Anna Hazare.
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

If it's an exception from which the ejb cannot recover, you should wrap the exception in a RuntimeException (usually an EJBException) and throw it.
With a RT exception (or a system exception) as it is called,

1. Associated transactions are automatically rolled back.
2. The bean is cleaned up (ejbRemove() will be called on the bean).

ram.
Ravi Kiran Va
Ranch Hand

Joined: Apr 18, 2009
Posts: 2234

Thank you very much for this
"Associated transactions are automatically rolled back. "


but are you sure that ejbRemove() will be called on the bean as i read that this method will be get called up when the container decides to remove the bean when it is idle for a long time .
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

but are you sure that ejbRemove() will be called on the bean


EJB Spec 3.0 section 14.2.2.2 and and 14.3.1 (specifically read about 'discarding instance')

Also take a look at http://java.sun.com/j2ee/1.4/docs/tutorial-update6/doc/Session6.html

ram.
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
ramprasad madathil wrote:With a RT exception (or a system exception) as it is called,

2. The bean is cleaned up (ejbRemove() will be called on the bean).

The spec just states the opposite:
EJB 3.0 spec section 4.4.3 Missed PreDestroy Calls
The Bean Provider cannot assume that the container will always invoke the PreDestroy lifecycle callback interceptor method(s) (or ejbRemove method) for a session bean instance. The following scenarios result in the PreDestroy lifecycle callback interceptor method(s) not being called for an instance:

- A crash of the EJB container
- A system exception thrown from the instance's method to the container
- A timeout [...] while the instance is in the passive state.


SCJP 5 (98%) - SCBCD 5 (98%)
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

You are right about the ejbRemove() and/or the preDestroy() methods.
I do still think that the bean instance will be discarded. Please refer to sections listed in my previous post.

ram.

Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
ramprasad madathil wrote:I do still think that the bean instance will be discarded. Please refer to sections listed in my previous post.

Yes, that's right. Also the container automatically releases managed resources when a bean instance is discarded (see ejb 3.0 spec 14.3.11).
Emmanuel Garcia
Greenhorn

Joined: Feb 24, 2009
Posts: 12
Ravi Kiran V

When you use explicitly a EJBException (RuntimeException and "System Exception" in the EJB world) is only for a callback methods and sometimes when you are in a bussiness method and the checked exception is internal and no bussiness.

And raise it is because you realize is a bad idea coontinue with the normal flow therefore is best idea is throws a EJBException
because the Container will do:

1- discard the instance bean
2- log the problem
3. roll back the transaction

But generally when you are in bussiness method and you have a checked exception you should do a call to setRollBackOnly()
and rethrow the checked exception if it is not in the interface method or continue with the bussiness method and check if the transaction
is alive with getRollBackOnly(), maybe it is the main reason to use a EJBException, avoid make extre job.

One more thing, with setRollbackOnly() call you tell to container, the transaction will not commit; remember all this is for CMT.

The exceptions for EJBs is interesting but complicated because there are things for the provider bean and things for the container.


Regards
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Throwing EJBException from a Method