openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: Optimistic Lock Exception not thrown with @version
Date Wed, 24 Aug 2011 15:00:49 GMT
  As you have explicitly acquired a lock, a
javax.persistence.LockTimeoutException perhaps would be more appropriate
than javax.persistence.OptimisticLockException.
  In either case, OpenJPA translates database level SQL exceptions by their
error code to application-visible exceptions such as
javax.persistence.OptimisticLockException. This translation is specified in
a resource file named "sql-error-state-codes.xml". 
  Given the wide variations of SQL error codes by different database
drivers, we could only populate this translator file with some of the known
error codes and it is by no means conclusive.

  In this case, for example, SQL error code 1222 from SQLServer database is
*not* mentioned in the translator file. So OpenJPA defaulted to a generic

  Normally, we add error codes for specific database as and when the users
encounter/report such errors.

For a quick turnaround, here is a suggestion:

1. extract the translator file "sql-error-state-codes.xml" from OpenJPA.jar
2. edit it. The edit should add the error code 1222 in <optimistic> or
<lock> clause (depending on whether the error should be translated as
OptimisticLockException or LockTimeoutException) of the appropriate database
dictionary section.
3. update OpenJPA.jar with the edited file

Please let us know if you carry out this experiment. We will then commit the
change to the original translator file.

Pinaki Poddar
Chair, Apache OpenJPA Project
View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message