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.
Of course just my 2 cents :-)
Miki<br /> <br />SCJP 1.4, SCBCD 1.3
posted 15 years ago
Your answer is abosultely correct. But my question is why entity beans can passivate with in transaction.
There is big difference between passivation of Session bean Vs. Entity bean, Session Bean passivation== serialize the bean Entity bean passivation== bean returns to pool of Entity bean.
So when Entity bean is passivated, its time for it to go back to pool,so transaction doesn't matter here.
Check out HF page 309.
Hope this helps. [ June 13, 2005: Message edited by: Meg Adal ]
posted 15 years ago
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!