This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
If container decides to use commit option A (entity stays locked), then it does not invoke ejbStore() after the transactions is commited. It also does not invoke ejbLoad() before the next business method, which runs in a new transaction. These two methods (transactions) can be run by different clients. Any ideas why EntityContext can be used in ejbLoad() and ejbStore() to get security information about THE client? These methods do not look like directly connect to the clients' calls.
ejbLoad() and ejbStore() are only used with Commit Option B and C in order to resynchronize the bean�s transient state with its persistent state.
Consider what happens when a client invokes a business method which requires the Container to transition a bean instance from the pooled to the ready state (by invoking ejbActivate()). The Container synchronizes the instance with the DB and then invokes ejbLoad(). As ejbLoad() runs in the transaction context of the business method and also has a client security context, it is therefore possible to obtain obtain client security information and to execute transaction methods from within ejbLoad().
Before the end of the business method, the Container must begin the synchronization process of the DB with the instance by invoking ejbStore(). This method runs in the transaction context of the previous ejbLoad() or ejbCreate() and still has a client security context, so anything you can do in ejbLoad() you can also do in ejbStore().