Session Bean Contract LifeCycle Enthuware

[Amandeep Singh]

Which of the following methods should be used by a session bean to clean up the resources that it has acquired before its removal?

1)ejbRemove

2)passivate

3)remove

4) setRollbackOnly

5) ejbPassivate

the correct answers are 1 and 5.

Is answer 3 is wrong because there is no such Remove method is present. But remove method is present in home interface for EJB 2.1. Only @Remove annotation is present. But again here we are talking about EJb 2.1 so remove method is present. Removing the bean also ensures that the resources are released.
But if you look at the explanation for the answer-
"
An ejb acquires resources in @PostCreate and @PostActivate() methods and it releases the same resources in @Remove and @PrePassivate methods.

If a bean is passivated and if the timeout occurs, the container does not call @Remove method.
"

So again what is the differnce between ejbRemove and remove method in home interface for EJB 2 methods?

[Ralph Jaus]

So again what is the differnce between ejbRemove and remove method in home interface for EJB 2 methods?

If the client calls the remove method on the home object, the container invokes the ejbRemove method on the corresponding bean instance.
[ December 20, 2008: Message edited by: Ralph Jaus ]

[Amandeep Singh]

if you look in EJB3 in Action, the remove and ejbRemove are shown as separate methods.


See at page-509, Table 14.2

[Ralph Jaus]

They are different methods. But in the end ejbRemove is called and this method is used for two situations. The SessionBean API says:

A container invokes this method before it ends the life of the session object. This happens as a result of a client's invoking a remove operation, or when a container decides to terminate the session object after a timeout.

If the client invokes the remove method on the home interface this corresponds to calling an @Remove method in EJB 3.

If the container calls ejbRemove to terminate the bean's lifecycle it corresponds to a call of a @PreDestroy method.

So in EJB 2.1 the two events are handled by the same method while EJB 3.0 allows to separate them.

[Jim Janssens]

EJB2.1: if you explictily call remove on the EJBObject, the corresponding ejbRemove() method of the session bean is executed prior to removing the actual bean instance.

EJB3: You have to mark a business method explicitly with the @Remove annotation. This will serve as a trigger for the container; after this method has executed, the container will remove the bean instance. The container will execute a method marked with @PreDestroy prior removing the instance.

So, @Remove is the trigger (like calling remove() on the EJBOBject with EJB2.1) and @PreDestory is the logic to execute upon removal (like the ejbRemove with 2.1). Also, if your session bean implements the session bean interface, you can only annotate the ejbRemove method with @PreDestroy (its not mandatory to annotate it, but you must not annotate any other method).

Btw; the @Remove can only be specified on SFSB's. As far as I know there is no way to explictly remove SLSB's from a client side perspective in 3.0 (unless you export an EJBOBject for a 2.1 and call remove, which is also valid on SLSB's) someone an idea about this ?

[Amandeep Singh]

Thanks Jim.

Yes the client can't explicitly remove the SLSB's.

As the container maintains pool of SLSB's. At some point the container decides that our bean should be removed from the
pool and destroyed (perhaps at server shutdown). The PreDestroy callback gives
us a chance to cleanly tear down bean resources before this is done.