In ejbcertificate.com, I read that the container synchronizes the instance's state before it invokes the ejbRemove() method. So that means if the bean is passivated... then the container has to call ejbActivate()->ejbLoad() and then ejbRemove(). I can't understand why the container has to go thru these process for JUST deleting the entity!!!
If the bean is passivated and a timeout occurs the server will not call the ejbRemove (just kill the bean). If the client calls remove() the server acts in the same way as the client would call another method on the bean, he will call ejbActivate (to serve the client request) and then call the ejbRemove().....
SCJP 1.4<br />SCBCD 1.3
Joined: Jun 08, 2004
Thanx peter for your reply.
Well I'm not talking about time out here. Say, the client is calling a remove() and the bean is in passivated state. What happens then ???
I can understand that we need to call ejbActivate to bring the bean out of the pool. But why this ejbLoad(), container doing all these work , JUSt to delete the entity !!!
Peter, Giju is talking about entity beans for which there is no timeout stuff as for stateful session beans
Giju, the behavior you describe is required by the spec (see section 10.5.3):
The container synchronizes the instance�s state before it invokes the ejbRemove method. This means that the persistent state of the instance at the beginning of the ejbRemove method is the same as it would be at the beginning of a business method (i.e., if the instance is not already synchronized from the state in the database, the container must invoke ejbLoad before it invokes ejbRemove).
The ejbRemove method can only be called when the entity bean is in the READY state. If the entity bean has been passivated it first needs to be reactivated (ejbActivate) and synchronized (ejbLoad) before being removed. I think you understand that but you don't see why ejbLoad has to be called if the bean will be removed anyway... Well, you have to see ejbRemove as just another business method which requires that the entity bean fully reflect the current state of the database. The container doesn't make any difference between a call to a business method and a call to the ejbRemove method when an entity bean is pooled and has to be readied again. The bottom line is that ejbLoad is always called directly after ejbActivate has been called. I have verified this information with BEA Weblogic 7 application server implementation, but I think other servers are behaving the same way
>Peter, Giju is talking about entity beans for which there is no timeout stuff as for stateful session beans
Well of course you are right (I've read over the ejbLoad :roll: ) but the answer is nearly the same, the server doesn't know (care) which method is called and so calls ejbActivate and then ejbRemove (for statefull session and for entity beans).
Joined: Aug 26, 2001
Right, but Giju's main issue was the ejbLoad being called before ejbRemove, I guess...