I retrieve data from DB and generate a value object containing this data. An user(first user) makes modifications on this data and submits these alterations to DB by EJB. Between the retrieval and the update submission another user(second user) updates these data. I need to know at the first user update effectivation if the data were modified. Any suggestions?
You describe a faily common problem. It can be solved at two levels:
1. DB level. Many DBs support optimistic transaction algorithms that would produce the behaviour you described. Using the SERIALIZABLE isolation level is a good guess, although a lower level may also work. For instance, if you use SERIALIZABLe transaction with Oracle in the scenario above, the second update (the one that happens after data has changed) will fail raising a "can't serialize transaction" error. You can catch this, and report to the client.
Note that this apporach requires you to use a single DB transactions for both requests made by the user (get data, update data). That may be unacceptable in certain scenarios, raising the next option.
2. Application level. In this approach, you maintain a version field on the entity, upgrading the version each time the data is updated. An update is only allowed if the version of the Value object that created it is the current version (i.e, the data hasn't changed). There are many spins on this notion, but that's the basic idea. You can find many descriptions of this pattern in TSS's patterns section (I suggest you read the later ones, old ones were flawed).
Hi, I think the only real place to catch all scenarios is in the DB. While app level version checking can detect where a change has already been committed, it cannot protect where two "simultaneous" updates are being applied to the same version. In this scenario the app level check would pass both updates but one would overwrite the other in the db.
Since entity beans do not allow concurrent access I don't see where the problem of applying two "simultaneous" updates to the same version would apply. Could you explain a little more.
Concurrent access applies to a single instance of an entity bean. In app servers which support multiple instances of the same entity bean (most major vendors except BEA ?) the simultaneous update scenario can occur. At least thats my understanding but I'm open to correction here.
I suppose starting with version 6.1, weblogic started using optimistic concurrency strategy (database locking) instead of pessimistic concurrency(exclusive locking) for Enity Beans.
We can end up with multiple instances of same Entity Bean(Same PK) even in BEA. So there is always a possibility of multiple update scenario and depending on database isolation level, call will proceed or fail.