• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Spec clarification

 
Ranch Hand
Posts: 528
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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??
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic