This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I am using Websphere application server 188.8.131.52.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
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.