openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: Optimistic Locking question
Date Fri, 20 Feb 2009 15:12:08 GMT
Hi Tim,
In general, detection of the OptimisticLockException condition won't happen
until commit time.  The expected isolation level for JPA is RC (Read
Committed).  So, until a commit action completes and makes the changes
"public", the check for an optimistic lock exception can't happen.  Or,
maybe I should say "shouldn't happen"...  :-)

Your testing with Derby is a little confusing.  With Versioned entities,
OpenJPA produces the same type of SQL for updating a Versioned entity.  We
have to increment the current Version column (X+1), given the current value
of the Version is X.  When this SQL gets flushed to the database, we are
relying on the database to tell us whether that SQL will be accepted or
not.  Maybe this can be detected at flush time, but more likely it won't be
detected until commit time.

The JPA spec is pretty wide open on this issue.  All that it really states
is that the optimistic lock condition must be detected at some point.  The
idea is to request the locks as late as possible to avoid serialization of
operations.  And, just so that the provider doesn't allow the overwriting of
data and throws the OptimisticLockException sometime before a commit()
completes for this condition, then the provider is okay.

Related to all of this is that I am assuming that all of your
experimentation did eventually end up with an OptimisticLockException.  And,
besides Derby, what other databases are you experimenting with?


On Fri, Feb 20, 2009 at 12:41 AM, Tim McConnell <>wrote:

> Hi, I'm a little confused about the OpenJPA optimistic locking behavior
> relative to the flush() and commit() methods. For example, if I modify an
> entity (which contains a version) in one transaction, do an em1.flush(), and
> modify the same entity in another transaction, and do another em2.flush(), I
> would expect to see an OptimisticLockException on the second flush. This
> does in fact happen like this on the Derby database, but not on any other
> databases I've tried. So, I'm wondering if I should instead expect the
> OptimisticLockException only when the transaction(s) end via the commit(),
> and not on the flush() ??
> --
> Thanks,
> Tim McConnell

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message