Spec clarification

[Marcelo Ortega]

The first line in point 4 on page 168 says:

The container can choose to passivate an entity bean instance within a transaction.

Within a transaction?
Entity beans use CMT, therefor a transaction cannot be left open. Having said this, being in a transaction would most probably mean that you are in the middle of a business method...
So the container can just stop the execution whenever it feels like it in the middle of a business method?

I know that for Stateful session beans the container will not passivate your bean if in a transaction. But i don't understand this for Entity beans.

Regards.

[Ugender Rekulampally]

Marcelo,
I hope I understood the question correctly.

The spec is talking about may be more than one method involving in a transaction, not single method. If transaction executing for a single method, it won't stop in the middle.

So for entity beans, there won't be a guarantee that same client calls the same bean to execute/finish the transaction. So that is why, you can't leave a transaction open here, But in case of a stateful session bean, the same client going to come back for that bean so there is a guarantee to finish transaction even though this is highly not recommended.

Hope this helps.

Thanks,
Ugender

[AmitKumar Jain]

But Ugender, entity bean is by default CMT and for a CMT bean, transaction lasts for a method only. How come then can it involve more than one method??

[Vijay Gade]

This is what I'm thinking:

Based on the transaction attribute, it would be decided whether the transaction is restricted to a single method, or would propogate further. For example, if the transaction attribute of a method bar() is Mandatory, then this method would enforce the method calling this method, foo(), to be in a transaction. Thus, if bar() fails, so would foo().

Please correct me if I'm wrong.

[Ugender Rekulampally]

Amit,
Assume below code is in Entity bean. and the addStock() and addEmp also in the same bean...




public void addAllData(String empID,String empName,String stockID,String stockName)
{
addStock(stockID,stockName);
addEmp(empID,empName,stockID);
}


addAllData is depending on two methods ...this kind of scenario I was thinking about..

Please add more details if I am missing something.

Thanks,
Ugender

[AmitKumar Jain]

Ugender,
I agree with your viewpoint.... infact I feel now that whats harm if I call any other bean's method(having Required attribute)... all will then run in same transaction.

As for passivation for entity beans is concerned, it is much different than session beans. For entity beans, container calls ejbStore before passivation and hence its state/data is updated in database. So there'l be no harm if it is passivated in a transaction. Whenever needed again, it can be activated and data can be loaded using ejbLoad

But in case of session beans, passivation means serialization or some similar mechanism to store the entire Session Bean Object to a persistent storage.

Now Im confused at this point here... can't the container can activate the session bean after passivation and continue the transaction?

[Ugender Rekulampally]

Amit,
"But in case of session beans, passivation means serialization or some similar mechanism to store the entire Session Bean Object to a persistent storage.


Now Im confused at this point here... can't the container can activate the session bean after passivation and continue the transaction?"

Yes it does(session bean won't go into passivation mode if its in the middle of a transaction), but that is not the recommended way. I think atleast one reason is to not do that way is, Lets assume a client started a transaction and didn't finish it. And wants to finish in next call and some how client dies? that bean won't be passivated since that is in the transaction. So this is very complex and confusing scenario.

There may be more reasons to not to recommend that way.

Hope this helps a bit.

Ugender

[ August 09, 2006: Message edited by: Ugender Rekulampally ]
[ August 09, 2006: Message edited by: Ugender Rekulampally ]

[cheenu Dev]

so does it means that you can have this scenario.

method1(){ - in tx (entity bean instance one serves it.)
- now passivates(in tx)
method2() - entity bean instance two serves it.
}

[AmitKumar Jain]

Absolutely...
Entity beans while passivation are living objects with no client state.
Any other instance can take up the role once any other method is called.