I am using WebLogic 7.0 and attempting to use what they call READ type Optimistic concurrency control in my EJB container. READ means that all fields will be used to determine if data has been modified since a user retrieved the record. (We have rejected using a version or timestamp field because it would mean adding the column to existing tables and would impact too many existing stored procedures and 3gl pgms.)

I have confirmed that using READ, WebLogic includes all columns in the Update where clause (so the values of all columns are being checked) and only modified columns are included as Set statements.

The problem is that this happens within one transaction. But in my application, there are really two transactions. One that reads the record and send it to the client (STRUTS) and a second when the client presses SAVE (after some client side think time).

Can someone confirm that this sequence (logically) is what needs to happen to implement optimistic concurrency in the backend??

1) EJB is found using some find method appropriate to the application
2) Data from EJB is moved to web client using TWO value identical objects (VO)
3) User later updates values in one of the VO's and presses SAVE button. Changed and unchanged VO's are sent to backend.
4) In backend (Stateless Session Bean), the correct EJB is found via findByPrimaryKey
5) Data values from EJB are compared to the second (untouched) VO. If they are identical, then the update occurs. Else, an optimistic concurrency exception is raised.


Thanks

Jerry

Hi!

From what I can see, the proposed solution will work. And I think it is the best you can do with the constraint that you cannot add a version column to the tables in the database.

/Tomas