Hi, 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 exception. 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: http://openjpa.208410.n2.nabble.com/Optimistic-Lock-Exception-not-thrown-with-version-tp6271170p6720526.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
