In the database concurrency strategy section this article
http://dev2dev.bea.com/lpt/a/458 mentions
At least one problem exists with both the exclusive and the database concurrency strategies: the possibility of lost updates. Imagine if two clients almost simultaneously try to update the same record in a table that is mapped to an entity bean. If no locks are held in the database, the result of the update operation that finished first will be overwritten by the second update.
I am not sure why is it mentioned that no locks are held.
Won't using the right transaction isolation level help prevent the problem. Is he talking about the case where the transaction isolation level is READ_COMMITED.
If it were REPETABLE_READ
TX1 reads a ROW A
TX2 cannot update the ROW A until TX1 completes so that TX1 is able to read the same data later in transaction?
What I dont understand is the relation betwen concurrency and ISOLATION LEVEL?
In the next para
This is achieved by setting the use-select-for-update element in weblogic-cmp-jar.xml to true (the default setting is false). As you can guess from the name, this action will instruct WebLogic Server to use "select for update" when loading entity bean data. The resulting database lock will be held until the transaction is completed, and therefore it's impossible for any other transaction to read or change data while the first transaction is running.
I am again confused. Wouldn't using the right isolation level help rather than using SELECT FOR UPDATE lock.
Thanks,
Pradeep