The idea of passivation is to save resources. I think if a tx is still opened (which is BTW a very bad practice to leave tx open across multiple business method calls) is considered that the client is "active" and the container would just waste time passivating the bean and reactivating it at any next moment.
I gussed something about passivation of session bean and entity bean, Please clarify am i right.
For Session beans, it has the possiblity of going out service from passivated state. If session bean supports passivate with in the transaction mean, it can go out service with out commiting the work. So that spec doesn't allow the container passivate when the bean instance in transaction.
But Entity Beans, before going into passivate state it updates the entity in the persistent store. So that the transaction doesn't matter commit or rollback. So that spec allows container to passivate a entity beans instance in transaction.
As Meg said, passivation of entity beans and session beans are very different. I think they are just called the same not to introduce to many call back functions .
So that spec allows container to passivate a entity beans instance in transaction.
NOPE! Keep in mind that activation and passivation are NOT associated with a transaction. Both ejbActivate() and ejbPassivate() for an entity bean are called within an UTC (unspecified transaction context). You are no longer in a tx, and no client info!
Miki<br /> <br />SCJP 1.4, SCBCD 1.3
I am going down to the lab. Do NOT let anyone in. Not even this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop