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.
You're very right, setting a higher level of isolation will prevent that from happening. The problem though is that all beans accessed by that transaction will run within the same isolation level and therefore more database locks will be held. Using the use-select-for-update deployment descriptor will set the "isolation level" only for the bean and not for the entire transaction. Other beans can have a lower isolation level set.
Using the use-select-for-update deployment descriptor will set the "isolation level" only for the bean and not for the entire transaction. Other beans can have a lower isolation level set.
I haven't understood the above. What do you mean by not for the entire transaction. Thanks,Pradeep
What I mean is that use-select-for-update deployment descriptor is not actually setting the transaction isolation level in any way. This is a very restrictive operation and setting a higher isolation level will degrade the performances considerable. In order to avoid this the use-select-for-update deployment descriptor will instruct the container to exclusively lock the mapping table independent of the isolation level used. It has the advantage that you can still assure data integrity even though the isolation level for the current transaction is set to a lower value.