views:

11

answers:

1

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 
+1  A: 

I have this question because my understanding is the OptimisticLockException occurs if there is race to commit the same row by multiple thread.

Yes, an OptimisticLockException will be thrown if the Version attribute of an entity is higher (i.e. has been modified by another transaction) at commit time than when it was read. This is illustrated by the figure below (borrowed from JPA 2.0 Concurrency and locking):

alt text

But I think this situation should never occur if isolation level app server is set to READ COMMITTED.

Why? When using a READ COMMITTED isolation level, non-repeatable reads may occur but:

  1. This won't affect in memory representation of data (e1 in the above example)
  2. Most of time, you don't re-read data
    • And even if you do (and perform a non-repeatable read), an entity might still get modified by another thread before you commit changes.

To sum up, READ COMMITTED won't prevent OptimisticLockException.

Pascal Thivent