Optimistic Locking question

[Tim McConnell <ti...@gmail.com>]

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

Re: Optimistic Locking question

[Tim McConnell <ti...@gmail.com>]

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 <ti...@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

Re: Optimistic Locking question

[Kevin Sutter <kw...@gmail.com>]

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 <ti...@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
>