Roger, if I understand you correctly, you say that during one business method call the bean can be activated and passivated? Did you read this in the spec? If yes where? I don't remember reading this, which would obviously explain the answer.
A component business call on an entity bean will require an activation of an entity bean instance and a passivation after the end of the method. It's in the OID.
And If I am thinking a bit with loud voice ... I am wondering why should the container ever do this? It seems very inneficient and it doesn't seem to make sens. Pasivation of an entity bean means that the bean goes back in the pool, and it doesn't represent anymore an entity from the database. If he does this during a business method (so before the method finishes) where/how does he store the information that the bean refers to that specific entity which he has to represent when he becomes active?
Every
EJB container has its own way of deciding when to passivate an instance. In the case of entity beans, the container can choose (by some means or other) to passivate an instance within a transaction. To passivate an instance, the container first invokes the ejbStore() method to allow the instance to synchronize the database state with the instance�s state, and then the container invokes the ejbPassivate() method to return the instance to the pooled state. Subsequently, the container will invoke ejbActivate() followed by ejbLoad() to enable the bean's state to be synchronized again with the database. At the end of the transaction, there will be an ejbStore() followed by an ejbPassivate().