This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
According to the spec at page 169 the container can passivate an Entity bean while it is in a transaction:
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 prepare itself for the synchronization of the database state with the instance�s state, and then the container invokes the ejbPassivate method to return the instance to the pooled state.
How is this possible and what will happen to the transaction? Thank you in advance /Magnus
Since the transactional state is maintained by the container and unlike session beans there is no conversational state here (which needs to be preserved)so I think passivation shud go Ok and morever this shud work only for CMT case.
Sudhir V<br />(SCJP 1.2, SCWCD, OCA, SCBCD)
Joined: Jun 05, 2003
Thank you Sudhir If I understand correctly the transaction will remain open and that would mean that the row in the database will remain locked to perserve isolation in the transaction. Maybe this is a very unusual situation where the transactions are very long. It seems like this would cause a lot of waiting for the rows to be unlocked. /Regards Magnus
Joined: Dec 25, 2002
Ya you are right Magnus!!! Probably the very thought of passivation within a transaction is to avoid the long term locking of rows and it makes sense coz the ejbLoad is going to be called upon activation. But this is a problem for transactions which needs the data to be unchanged. Guess when the spec says "container can choose to passivate an entity bean instance within a transaction" it means "You better keep your transactions short or else I may not guarantee a complete lock for ya". What do you say?
Joined: Jun 05, 2003
"You better keep your transactions short or else I may not guarantee a complete lock for ya"
I do not have an answer for this, but it seems very irresponible if the container have this attitude It seems to be no point in keeping the transaction open if it doesn't keep the lock on the row. Maybe this just gives the container the oppertunity to remove the bean from memory while more active beans need it more, but at the same time keep the transaction open and the row locked. This is just a more or less educated guess... /Magnus
subject: Passivate in entity bean within transaction