This week's book giveaway is in the OCAJP forum.
We're giving away four copies of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) and have Khalid A Mughal & Rolf W Rasmussen on-line!
See this thread for details.
Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Digambar Daund
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic