wood burning stoves
The moose likes Object Relational Mapping and the fly likes JPA - Optimistic Lock Violation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA - Optimistic Lock Violation" Watch "JPA - Optimistic Lock Violation" New topic

JPA - Optimistic Lock Violation

Johnny Caimbridge

Joined: Nov 15, 2010
Posts: 8

I am using JPA in a relatively simple way, but I'm running into optimistic lock violation exceptions. My understanding is that this happens when an update is performed on version_a of a record when there exists a newer version_b that has already been committed by another transaction. The odd thing is that I am doing no such thing in my application.

This is on a DB2 database with OpenJPA (not JPA 2.0). The application server is IBM Websphere 7.0.

The erroneous behavior differs based on the order in which the above sections of code are executed.

Case 1) If (in separate threads) SECTION_A executes before SECTION_B (i.e. ANY entity of type BobRun is read with em.find() before a NEW entity of type BobRun is created with em.merge()), then the following error occurs on the commit() of SECTION_B:

Case 2) If (in separate threads) SECTION_B executes before SECTION_A (i.e. a NEW entity of type BobRun is created with em.merge() before ANY entity of type BobRun is read with em.find()), then on the find() call of SECTION_A, a "Descriptor index not valid" error occurs (I copied this from the "getMessage" output of the exception. For whatever reason there is no stack trace ... maybe this IDE is bugging).

There is no other situation in which a BobRun entity is read or written other than SECTION_A and SECTION_B.

The odd part is that there is no concurrent modification taking place (there is only one place--SECTION_B--where a single BobRun entity is created). On top of that, if instead of using em.find() on the PK in SECTION_A I run a JPQL statement which simply selects on the BobRun PK, there is no error in either of the above cases and everything works as expected.

I'm pretty stumped here.
Kevin Reynolds

Joined: Mar 07, 2010
Posts: 8

I am having the same problem. I think the cause of my issue is that when I retrieve the record that I need to update using the find method of EntityManager, my field that is annotated @Id is not populated however the _id and _oid of the pcStateManager have the correct pk value.

public class SubscriptionGroupEntity {
@Column(name="subscription_group_id", nullable=false)
private Long subscriptionGroupId;

code to find:
SubscriptionGroupEntity sge = em.find(SubscriptionGroupEntity.class, subscriptionGroupDTO.getSubscriptionGroupId());

entity values after find:

pcStateManager values:
_id = 9658079231011
_oid = 9658079231011

stack trace:
432229 alert-jpa TRACE [http-nio-8443-exec-7] openjpa.jdbc.SQLDiag - flush: org.apache.openjpa.kernel.PDirtyState for
432245 alert-jpa TRACE [http-nio-8443-exec-7] openjpa.jdbc.SQL - <t 642761973, conn 55112940> executing prepstmnt 143
7235569 UPDATE subscriptiongroup SET active = ? WHERE subscription_group_id IS NULL [params=?]
432245 alert-jpa TRACE [http-nio-8443-exec-7] openjpa.jdbc.SQL - <t 642761973, conn 55112940> [0 ms] spent
432245 alert-jpa TRACE [http-nio-8443-exec-7] openjpa.Runtime - An exception occurred while ending the transaction.
This exception will be re-thrown.
<openjpa-2.1.1-r422266:1148538 nonfatal store error> org.apache.openjpa.util.OptimisticException: Optimistic locking err
ors were detected when flushing to the data store. The following objects may have been concurrently modified in another
transaction: [com.alert.smithford.dao.model.SubscriptionGroupEntity-9658079231011]
at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2310)

Did you happen to find the solution to the issue you encountered?

Also, if there is anyone else out there has any suggestions for resolving this issue, I'd appreciate it very much.

OpenJPA version 2.1.1
Tomcat 7
MySQL 5.1.50
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Pavel Vyazankin

Joined: May 04, 2012
Posts: 1
I have the same issue. Have anybody find a solution?
I agree. Here's the link: http://aspose.com/file-tools
subject: JPA - Optimistic Lock Violation
It's not a secret anymore!