Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB 3.0 statefull session bean life cycle dout

 
Sudarshan Sreenivasan
Ranch Hand
Posts: 188
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 329
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Sudarshan Sreenivasan
Ranch Hand
Posts: 188
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Extremely well put ... thanks alot
 
Juggy Obhi
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Sergio Tridente
Ranch Hand
Posts: 329
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic