• 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:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Passivate in entity bean within transaction

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Magnus Stattin
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sudhir V
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Magnus Stattin
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Sudhir


"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
 
Watchya got in that poodle gun? Anything for me? Or this tiny ad?
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic