aspose file tools*
The moose likes Threads and Synchronization and the fly likes Is is possible to get OptimisticLockException when READ COMMITTED isolation level is set at appsrv? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Is is possible to get OptimisticLockException when READ COMMITTED isolation level is set at appsrv?" Watch "Is is possible to get OptimisticLockException when READ COMMITTED isolation level is set at appsrv?" New topic
Author

Is is possible to get OptimisticLockException when READ COMMITTED isolation level is set at appsrv?

Digambar Daund
Greenhorn

Joined: Oct 27, 2009
Posts: 2
I am using Websphere application server 7.0.0.0.9 with ;OpenJPA 1.2.3-SNAPSHOT'.
I have Set property of jdbc data source webSphereDefaultIsolationLevel=2 (READ COMMITTED).
I have this question because My understanding is the OptimasticLockException occurs if there is race to commit the same row by multiple thread.
But I think this situation should never occur if isolation level app server is set to READ COMMITTED.

This is exception I am getting..
<openjpa-1.2.3-SNAPSHOT-r422266:907835 fatal store error> org.apache.openjpa.persistence.OptimisticLockException: An optimistic lock violation was detected when flushing object instance
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

The defaut setting for OpenJPA's lock manager is based on a versioning policy, which is an optimistic locking approach. In order for this to work reliably the transaction isolation level must be READ COMMITED at minimum. This isolation level prevents dirty reads (uncommitted changes by another transaction), but it does not prevent an optimistic locking policy violation. Within the scope of a transaction, when a read lock is aquired it will be released immidiately after the select completes, as opposed to at the end of the transaction - which would be the case for write locks. Nothing prevents another transaction from readnig, modifying and writing back the selected record in the meantime, thereby incrementing the version for that record. When the transaction that read - the now old version of - the record tries to write back changes, the locking manger will notice that the version of the record to be committed is older than the version stored in the database. This will cause it to throw an OptimisticLockingException.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is is possible to get OptimisticLockException when READ COMMITTED isolation level is set at appsrv?
 
Similar Threads
solution for EJB3.0 and Open JPA in WAS7
Question about TRX_REPEATABLE_READ
Transaction Isolation Levels
Locking problems using JDBC and MS SQL Server 2008.
isolation level in EJB2.0