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 ]
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.
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?