I'd greatly appreciate if you could help figure out the following.
ejbLoad() and ejbStore() can run on an entity bean that is in a method ready state. The bean can be in a such state when a client invoked a business method or commit option A /commit option B is used (bean remains in a method ready state, just does not service any client's call).
Q1. How many times are ejbLoad()/ejbStore() called per transaction? Can they be called more than once?
My answer would be that these methods are invoked at least once (but can be invoked more than once) per transaction. That is what the spec says (section 10.5.1):
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.
Q2. Can ejbLoad()/ejbStore() be invoked on a bean that is in a method-ready state but not in a transaction (i.e. uses commit option A or B and does not currently service the client's method call)?
If ejbLoad()/ejbStore() CAN be invoked on a bean that does not currently service the client's method call (as far as I can see there is nothing in the spec that says otherwise, refer to the quote from the spec above) the transaction context will be "unspecified" plus there is no client security info (bean does not service any client's method call).
However, the spec says that the entity bean can access resource managers/other beans plus get client security info and trnx related information when in ejbLoad()/ejbStore() (section 10.5.5). This where I get confused
If ejbLoad()/ejbStore() CANNOT be invoked on a bean that does not currently service the client's method call then everything is clear . In this case a bean will always be associated with the client and run in "meaningful transaction context" (provided that a business method that caused these methods' invocation has appropriate transaction attribute) when ejbLoad()/ejbStore() is invoked by the container on the bean.
Thanks a lot for reading and your answers.
[ June 30, 2004: Message edited by: Alex Sharkoff ] [ June 30, 2004: Message edited by: Alex Sharkoff ]
Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Joined: Apr 11, 2004
Would be really good to hear your thoughts on this subject
quote: --- If ejbLoad()/ejbStore() CANNOT be invoked on a bean that does not currently service the client's method call then everything is clear . In this case a bean will always be associated with the client and run in "meaningful transaction context" (provided that a business method that caused these methods' invocation has appropriate transaction attribute) when ejbLoad()/ejbStore() is invoked by the container on the bean. ---
Because: The entity bean can be in one of three states, �Does Not Exist�, �Pooled� and �Ready�. The entity bean only enters the ready state upon a client request.
From the spec page 169 --- An instance transitions from the pooled state to the ready state when the container selects that instance to service a client call to an entity object. ---
I think that�s an answer to your question because in your quote from the spec you mention that ejbLoad and ejbStore can only be called when the entity bean is in the ready state and the specs says that then the bean is always associated with a client.
The spec guarantees that you can access client specific information in ejbLoad and ejbStore, so for me that means that ejbLoad and ejbStore is not called by the container between client initiated transactions in option A and B. The container can choose to synchronize with the entity in the database as it pleases between client-initiated transactions but if it does then these synchronizations must not be followed up by calls to ejbLoad and ejbStore.
The spec has this note (page 187) about option B (and C) that makes sense given the explanation above.
--- Note: The Bean Provider relies on the ejbLoad() method to be invoked when commit options B and C are used in order to resynchronise the bean�s transient state with its persistent state. It is the responsibility of the container to call the ejbLoad()method at the beginning of a new transaction when commit option B or C is used. ---
The spec also has the following note about ejbLoad (page 173)
--- This method executes in the transaction context determined by the transaction attribute of the business method that triggered the ejbLoad method. ---
The spec does not mention anywhere the possibility that ejbLoad or ejbStore can be called by the container unrelated to a client call. The transaction context of ejbLoad and ejbStore is only unspecified when the transaction attribute of the business method which triggered the call to ejbLoad or ejbStore was NotSupported, Never, or Supports.
Kind regards Christian [ July 10, 2004: Message edited by: Christian Dauer Th. Sellberg ]