jQuery in Action, 2nd edition*
The moose likes EJB and other Java EE Technologies and the fly likes concurrency and transaction isolation level Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "concurrency and transaction isolation level" Watch "concurrency and transaction isolation level" New topic
Author

concurrency and transaction isolation level

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

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


Groovy
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Pradeep,

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.
Regards.


I think, therefore I exist -- Rene Descartes
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Thanks Valentin.

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
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi 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.
Regards.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Thanks Valentin.Great explanation.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
You're very welcome Pradip
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: concurrency and transaction isolation level
 
Similar Threads
Deadlock problems with Hibernate/Spring/MS-SQL
JDBC manually commit
entity bean behaviour
Original Data Verification before Update
Data concurency