According to EJB Spec 2.0 , the container can passivate the entity bean in middle of transaction. The following is paragraph from ejb spec.
"The container can choose to passivate an entity bean 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."
So if container passivate the bean in middle of transaction then it would invoke the ejbStore method and would update the database. So we are updating the database with-out knowing the transaction result ( commit or rollback ) In case of rollback, it would put the database in inconsistent state.
what i get from ur reply is this.. once the container acquires the lock for a particular row in the database for a transaction, the lock will be released only after the transaction completes, no matter whatever happens with passivation..am i right ???
yes, that's correct. Notice that "passivation" in Entity Beans is not the same as passivation in Stateful Session Beans. For Entity Beans it's only a "change of their role", not a "swap out to disk", although their state may be written to the disk too in ejbStore().