aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes EJB 3.0 statefull session bean life cycle dout Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "EJB 3.0 statefull session bean life cycle dout " Watch "EJB 3.0 statefull session bean life cycle dout " New topic
Author

EJB 3.0 statefull session bean life cycle dout

Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Hi,
Chap 3 of EJB 3 in action (Debu Panda) page no 99 states (9th point of sfsb life cycle call backs) that
If the client requests the removal of a bean instance, it is first activated if necessary and then destroyed.


Does this imply that in certain situations the postActivate methods will be invoked and then the @Remove method will be called.

If yes then which are the situations in which the container is likely to call postActivate and why ... as i do not see the need to activate a bean just to destroy it !!

Thanks
Vijay Ramalingam
Greenhorn

Joined: Jun 02, 2006
Posts: 18
i guess the reason would be to call PreDestroy method on the bean instance or on the call back handler....so it needs to activate the bean instance.
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

Originally posted by sid sree:
Does this imply that in certain situations the postActivate methods will be invoked and then the @Remove method will be called.


Methods annotated with the @Remove annotation are business methods. As per the ejb core specification, the Container must activate a passivated bean before running any business method on that bean. That's why @PostActivate is called before the @Remove method.

A @Remove method is not used exclusively for indicating that the bean can be removed. It may perform all the business logic you want.
[ September 24, 2008: Message edited by: Sergio Tridente ]

SCJP 1.4 (88%) - SCJP 5.0 Upgrade (93%) - SCWCD 1.4 (97%) - SCBCD 5.0 (98%)
Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Extremely well put ... thanks alot
Juggy Obhi
Ranch Hand

Joined: Jul 02, 2007
Posts: 51
No Doubt, it was a brilliant explanation but with the clarification of one doubt i have another doubt popped out.

What is we do not have any business method to be called on the Passivated bean. Say we don't have @Remove method. Why don't we distroy the passivated bean there itself. Why to bring it back to life when the motive is killing(In case there is not any Business method to be called).


It does not matter how many times you fall,what matters is how many times you stand back.
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

Originally posted by Juggy Obhi:
What is we do not have any business method to be called on the Passivated bean. Say we don't have @Remove method. Why don't we distroy the passivated bean there itself.


How would you do that? What mechanism other than calling a @Remove method would you use to tell the container that it may destroy your bean's instance?
Jair Rillo Junior
Ranch Hand

Joined: Aug 27, 2008
Posts: 114
A client can destroy a Statefull ONLY calling its @Remove method (or mapped with <remove-method> in DD).

Sergio: Nice explanation about @Remove be a Business method, I didn't know that


Regards, Jair Rillo Junior
http://www.jairrillo.com/blog, SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 5.0, IBM SOA Associate (Test 664).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EJB 3.0 statefull session bean life cycle dout