Stateful beans passivation

[Viktor Sadovnikov]

Hi,
Pages 206-07 in HFE are dedicated to passivation of BMT stateful session beans. One page states: "A stateful session bean will NEVER be passivated while the bean is still in a transaction!". On the other page you see that one of the things the BMT bean can do in ejbPassivate() is to "get a transaction reference, and call methods on it".
How does the bean come to ejbPassivate() if it has a transaction? Is there anything I miss here?
Thanks, Viktor

[Rashmi Tambe]

Hi Viktor,
Getting a transaction reference and being in a transaction are two different things.
1. Being in a transaction : it means that, in the SF bean, a tx has been started in one method and closed in other. And ther other method is still not called by client . As a result, u cannot passivate a bean.
2. Getting a transaction reference : this means getting a reference to UserTransaction object associated with the context, which u can use to commmit, rollback the tx or check the tx status.

How does the bean come to ejbPassivate() if it has a transaction? Is there anything I miss here?

u r right. Bean would come to ejbPassivate only when it's not in a tx. But when tx is completed , and it comes to ejbPassivate , it can always get access to the UserTransaction object.
Hope this makes clear.

[Viktor Sadovnikov]

Hi Rashmi,
I'm glad your understanding of the passivation completely matches with mine But I still do not see a point in getting UserTransaction object

But when tx is completed , and it comes to ejbPassivate , it can always get access to the UserTransaction object

I read UserTransaction SessionContext#getUserTransaction() API and did not anything about getting UserTransaction, where there is no transaction, and what you can do with this. The bean is being passivated, all transactions are done, clients forgot to call remove() and went to bed. On which transaction reference the bean will call methods?
Regards, Viktor

[Reid M. Pinchback]

I think it might help to keep in mind the difference between how a transaction is actually implemented, versus how transactional state is represented.
Transactions are kept track of in relation to the thread of execution, but the UserTransaction object isn't itself some objectified transaction. It is only a hook to give you access to transaction information. Its behaviour is very much like the java.lang.Thread class, in that some of its methods do stuff in a way that is associated with your current thread, not with an object reference. By making it an object instead of a class with static methods, the container vendor remains free to implement UserTransaction in whatever way they think is best.
So if you have code like:
UserTransaction trans=context.getUserTransaction();
trans.begin
...
you haven't caused some transaction referenced by 'trans' to begin. You've caused a new transaction to be created, begun, and be bound to your current thread of execution.
So the point of getting the UserTransaction object is to get something that will allow you to create a transaction or query the status of any pre-existing transaction.
As to why you'd want to create a transaction in ejbPassivate, I'd agree that it is a pretty esoteric situation, but at least conceptually you might want to do stuff like write some information to a database (something that would help you recover your state during ejbActivate) and/or toss some messages to a JMS queue. If it made sense to bundle multiple things within a transaction to ensure that they all commit or all rollback together, then you'd need to create a transaction for that.

[Vishwa Kumba]

Well explained! Reid