HI, If the Statefull session bean is in passivated state and then client calls remove()....i guess the bean will be activated first and ejbRemove() will be called.....am I right...?? Just to confirm!!! Amol
Hi Leena, Thanks for reply. Thats the only situation the HFEJB dosnt cover in explaination for statefull beans killings. When bean is passivated and it time outs, thats the case when ejbRemove() is not called ...this is specifically mentioned on HFEJB. What i thought is that the statement 'Container will not bring a bean out of passivation just to kill it' was may be refering to that scenario..........(may be container would like to be fair with bean and reduce chances when ejbRemove() is not called...just to let it clear stuff its holding in bean...) But Im not too sure about actual answer......so if you have gone through specification can u refer me to a page in it?(i've not yet touced ejb spec.).
" The Bean Provider cannot assume that the Container will always invoke the ejbRemove() method on a session bean instance. The following scenarios result in ejbRemove() not being called on an instance: - A crash of the EJB Container. - A system exception thrown from the instance�s method to the Container. - A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way. "
The specification do not mention anything about the passivate state... I agree that you spend resources... but.... if you have some logic or verification or desalocation of resources??? The ejbPassivate callback method have to close connections, do things for the session bean that will be stored.... not removed....
HFEBJ says that on stateful session, ejbRemove may be missed if 1) server crash 2)bean timeouts in passive state 3)system exception comes
so now I expect that bean may be in passivated state when remove comes.....that probablity is good one. And if container doesnt get it in activated state and kills bean directly, the above list would include the fourth element...which would make spec incomplete ...... Heance I guess it MAY be shifting it to activated state...unless spec says that its gonna be container managed..........(how I want it should not be!!!) Amol
A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way.
So, no doubt - from the passive state there is no way to invoke the ejbRemove method. It is also being shown in the 'Stateful Session Bean State Diagram' on page #84.
Further down on page #89 on 2.1 spec:
If the session bean instance allocates resources in the ejbCreate<METHOD> method and/or in the business methods, and normally releases the resources in the ejbRemove method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.
Not exactly exciting to know that we can't rely on the fact the ejbRemove is being called every time. At least the specification is very clear about it.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.