openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <tim.mcco...@gmail.com>
Subject Re: Optimistic Locking question
Date Fri, 20 Feb 2009 16:13:14 GMT
Thanks Kevin for the thorough explanation. BTW, I'm testing with Derby, DB2, 
Oracle, and PostgreSQL.....


Kevin Sutter wrote:
> 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?
> 
> Thanks,
> Kevin
> 
> On Fri, Feb 20, 2009 at 12:41 AM, Tim McConnell <tim.mcconne@gmail.com>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
>>
> 

-- 
Thanks,
Tim McConnell

Mime
View raw message