Hi i am using Weblogic server 7.0 and intend to use 2 approaches to access customer profile table.
The 1st approach use entity bean to perform online transaction like changing password, update particulars. The 2nd approach is to use session bean direct JDBC query the customer profile table, and this is for batch processing like update all customer info, which is thousands of records.
Now i have a doubt that while the user online retrieve his record through entity bean loaded in the EJB container, and the backend batch job hit the database through JDBC and change his record. How is the changes to his record be synchronized to the entity bean?? Is there any other better approach to avoid this problem??
Taking a look at section 17.7 in the EJB 2.0 spec. tells me that you have a potential problem here! From what I can see, you are not guaranteed update of the Entity Bean if a SessionBean changes data!! The following texts are from the EJB spec:
- An example (not realistic in practice) is...
- This case is challenging...
So this is not easy :-)
One solution can be to describe you entity as a Data Transfer Object, write an SLSB with methods getEntity(PK pk) and updateEntity(Entity entity) methods. The Entity class should contain persistent data, getters and methods for changing the object's state (setters or other business mehtods). When ready with updates, the client code is responsible for calling the updateEntity(...) method. (This differs significantly from the Entity Bean idea with automatic update by the EJB container.)
Besides updating the database, the update method also have to check that the data in the database (before update) is consistent with data in the object, i.e. check that no other client code has changed the data. This will add one extra step in code, as compared to an Entity Bean.
This solution will work when you have batch processes changing data via an SLSB (or directly into the database).
See the Comain Data Transefer Object pattern i Floyd's excellent EJB pattern book!!!
The spec says the container will call ejbLoad whenever there is a nead to synchronize the entity bean.
If you are making direct updates to the database table I would recommend setting the <db-is-shared> attribute to "true" and the <concurrency-strategy> to "database". This will cause the container to re-load the data from the database at the start of each transaction.
Of course your containers ability to cache this entity bean across a transaction but that is the penalty you pay for making direct access through JDBC.
David, not only the two attributes you considered must be set. You must also be aware of the transaction attributes of each method.
Imagine a session bean A which performs multiple getXXX-operation on a entity bean B. If you specify no transaction context for the getXXX-method of entity bean B the method will execute under the same transaction context as bean A. That means the container will _not_ reload the data on every getXXX call - whether you changed the data directly via jdbc or not. To achieve this behaviour you _must_ set the transaction attribute of the getXXX-method to RequiresNew.