Additional methods which might be called when invoking ejbRemove

[Sudhir V]

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

[Reid M. Pinchback]

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...

[Keith Rosenfield]

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.

[Magnus Stattin]

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]

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]

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.