confusion reg ejbLoad

[B.Sathish]

One of the chapter 6 mock exam answers in HFEJB says that ejbLoad() and ejbStore() can be called by the container in any order and anytime when the container wants even when there is no business method from the client. I am confused by this. I thought the bean would be loaded only when there is a business method call from the client. Can someone give me an example of a scenario when the bean is loaded WITHOUT there being a business method call from the client. What's the point in doing that? Because, anyway when the business method call comes, the bean's data would have become stale and it has to be re-loaded right? So why would be bean ever get loaded without there being a business method call from the client? The same for ejbStore(). Why would the bean's state be updated to the database without there being a business method call that puts an end to a transaction? How can one say that the container can call ejbLoad and ejbStore whenever it wants?

[Peer Reynders]

Originally posted by B Sathish:
One of the chapter 6 mock exam answers in HFEJB says that ejbLoad() and ejbStore() can be called by the container in any order and anytime when the container wants even when there is no business method from the client.

Question 15 (page371) only mentions ejbLoad, epbPassivate, and setEntityContext, there is no mention of ejbStore anywhere.

Originally posted by B Sathish:
Can someone give me an example of a scenario when the bean is loaded WITHOUT there being a business method call from the client.

Question 16 (page371) gives you that scenario. ejbLoad() could be called as part of an ejbRemove invocation (which could be invoked through the component interface or home interface) to set up for cascading deletes.
EJBObject.remove() is not considered a business method as it is part of the EJBObject interface not the component interface you extend from it, EJBHomeObject.remove(Object) and EJBHomeObject.remove(handle) are not considered (home) business methods as they are part of the EJBHome interface not the home interface that you extend from it.

[B.Sathish]

I agree with you Peer, but in page 369, question 10, it says business method can get called directly after load and all that. It says load, store and business methods can be called in any order. That's what's bothering me

[Peer Reynders]

That refers to page 169 of theEJB 2.0 Spec.

When an entity bean instance is in the ready state, the instance is associated with a specific entity object identity. 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. A business method can be invoked on the instance zero or more times. Invocations of the ejbLoad() and ejbStore() methods can be arbitrarily mixed with invocations of business methods. An ejbSelect<METHOD> method can be called by a business method (or ejbLoad() or ejbStore() method) while the instance is in the ready state.

Again the specification designers are trying to give the server vendors some leeway for performance enhancements. The object interaction diagrams are from the bean providers view - however they may not reflect what is actually happening on the server - its good enough if the bean provider "can't tell the difference" (which doesn't include creating instance variables to count the number of ejbLoad and ejbStore invocations).

If your J2EE application owns its persistent store it makes no sense to call ebjLoad every time a business method method is called - the bean is the master of the information - the information will only change through the bean - so if it changes the bean knows about it, because it changed it - in that case the Application Server Administrator can configure the bean to omit the unnessary loads.

If a business method doesn't change the entity's state there is no point in calling ejStore().

If your J2EE application uses a persistent store that is isolated - i.e. not other application or reports access it directly - and losing the entity state through a server crash isn't that critical a concern then the ejbStore invocations could be deferred until a time where server resources are more readily available - at what point saving the "dirty" entity back to the persistent store isn't going to impact overall performance.

[B.Sathish]

Thanks for your detailed reply. I understand it. But I feel exam takers should not be burdened with such container vendor implementation details. The exam taker should look at things from a pure Bean Provider point of view. Where exactly has the line been drawn is a bit unclear to me from the exam point of view. I was unable to answer quite a few questions in the mock-exam for chapter 6 in HFEJB because the chapter content talks from a bean provider point of view, but the mock-exam questions don't.

[Peer Reynders]

Originally posted by B Sathish:
But I feel exam takers should not be burdened with such container vendor implementation details.

There is a good reason for it in this particular case. Judging from the OIDs you could get the impression that ejbLoad would always run before the business method and ejbStore always runs after the business method - so you could get the idea to stick some "common code" in either of these. The specification then tries to make make painfully clear that this is not the place to put "common code". ejbLoad and ejbStore are part of the synchronization cycle - nothing else. If you have common code stick it into helper methods and call it at the beginning or the end of the business method.