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
I hope this answers your question.