• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Additional methods which might be called when invoking ejbRemove

 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HFE Pg 371 ques 16 says that only ejbLoad and ejbActivate might be called during the ejbRemove invocation. What happens if the method is already in the method ready state, does'nt ejbStore needs to be called to store the present state? Eventhough the data is going to be deleted, any database triggers associated with a data change shud be allowed to be fired i.e. the database shud be allowed to see the data change before it gets deleted. right!!!
Thanks
Sudhir
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the business methods were invoked in the context of a transaction, then a commit would have happened at the end of the transaction. The ejbStore would have happened as a part of the business method before ejbRemove could be a factor.
I think the issue only comes up when you don't have a transaction, or maybe more to the point you didn't specify a transaction, and you don't know what the container will do. Page 499 talks about this. I'd say that since the question doesn't mention transactions, you don't know if ejbStore will be invoked or not. HFE makes the point often enough that the test assumes "bean law", and since "bean law" doesn't say that ejbStore must be called, that is probably why it isn't listed as a valid answer.
Hopefully Kathy or Bert will weigh in...
 
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Reid,

Originally posted by Reid M. Pinchback:

I think the issue only comes up when you don't have a transaction, or maybe more to the point you didn't specify a transaction, and you don't know what the container will do.


Isn't it the case that entity bean methods will always run in a transaction since an entity bean can only use CMT. When using CMT a transaction attribute must be defined for all methods. I also don't understand why ejbStore is not a valid answer. What if the entity bean's state is not consistent with the persistant store at the time of the removal? I know that ejbLoad will ensure that they are consistent, but couldn't that result in lost data. The fundamental question that needs to be answered in order to clear up this confusion is when is the ejbStore called? Does the spec guarantee the invocation of this method or is it up to the container? I will research the spec and let you know what I find.
 
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
I found this at page 552 in the spec:


Added requirement that the Bean Provider must use only the Required, RequiresNew, or Mandatory
transaction attributes for methods defined in the home or remote interface of an entity bean with EJB 2.0
container-managed persistence.


I agree with Reid's previous post. The beans state can only be changed from a business method, and the container will always calls ejbStore and synchronize the bean with the database at the end of a transaction.
There seems to be no need to update a row in the database that is just about to be deleted. The reason why the container needs to call ejbLoad and get the bean consistent with the persistent store is for the cascade deletes to be correct.
This is a complex issue, please correct me if I'm wrong.
/Magnus
[ January 19, 2004: Message edited by: Magnus Stattin ]
 
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
What about the case if removal is part of the transaction? Example in Oracle, delete statements do not come under DDL so they do not have an implicit commit.
Thanks
 
Keith Rosenfield
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Magnus,
With all due respect I don't think that Reid was saying as you stated

the container will always calls ejbStore and synchronize the bean with the database at the end of a transaction.


I searched the spec to find out when ejbStore is guaranteed to happen but could not. This quote from the spec makes it seem as though it's up to the container's discretion.

While the instance is in the ready state, the container can synchronize the state of the instance with the state of the entity in the underlying data source whenever it determines the need to, in the process invoking the ejbLoad() and ejbStore() methods zero or more times.


Is there someone who can shed some light on this?
Thanks.
 
Weeds: because mother nature refuses to be your personal bitch. But this tiny ad is willing:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic