From dev-return-10585-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Fri Feb 20 15:12:38 2009
Return-Path:
Delivered-To: apmail-openjpa-dev-archive@www.apache.org
Received: (qmail 23225 invoked from network); 20 Feb 2009 15:12:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 20 Feb 2009 15:12:37 -0000
Received: (qmail 56115 invoked by uid 500); 20 Feb 2009 15:12:36 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 55950 invoked by uid 500); 20 Feb 2009 15:12:36 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 55939 invoked by uid 99); 20 Feb 2009 15:12:36 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 07:12:36 -0800
X-ASF-Spam-Status: No, hits=2.2 required=10.0
tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates 209.85.132.242 as permitted sender)
Received: from [209.85.132.242] (HELO an-out-0708.google.com) (209.85.132.242)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 15:12:29 +0000
Received: by an-out-0708.google.com with SMTP id d40so334425and.18
for ; Fri, 20 Feb 2009 07:12:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=/rVv4rZZuOJQCE4pmSRBsRLeu8WalldoD4iRijyxIO8=;
b=HK9dcFeli7N2fqIcZFsOfYfaC3ZXQtq6dTV4U8AfHKscU0x2I6cJ9eB9aIvSYWA2Na
LhA5V4bUR1psYaKBLaQiQzWk3AW9LJHG43wZCqLpe+bMeJc2MDzXVNPDKgLyein2ZZpO
D/M60S4N6UDpquK0H0/Was3ysKnihaBTO5LnE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=rjTCS50IqlROVuFnLLdVG/dpZW//1FZApAFxPrzE65irkaSdMwo+Nk1gsHtWIFH7oS
+LbQazJvhOkXamcvPr6z2VgNt/diH2UFKTjlIOPaMmbvtO60Lg2x7MB+PRPzaNgsz9/I
43QSnl4Lci2LFa8TKPxAHDLaO+2XiQsHBZVAQ=
MIME-Version: 1.0
Received: by 10.142.12.14 with SMTP id 14mr456984wfl.120.1235142728086; Fri,
20 Feb 2009 07:12:08 -0800 (PST)
In-Reply-To: <499E5096.30700@gmail.com>
References: <499E5096.30700@gmail.com>
Date: Fri, 20 Feb 2009 09:12:08 -0600
Message-ID: <89c0c52c0902200712v26f2bd68ocf1df9140f596803@mail.gmail.com>
Subject: Re: Optimistic Locking question
From: Kevin Sutter
To: dev@openjpa.apache.org
Content-Type: multipart/alternative; boundary=000e0cd2e2d28df52104635b130c
X-Virus-Checked: Checked by ClamAV on apache.org
--000e0cd2e2d28df52104635b130c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 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
>
--000e0cd2e2d28df52104635b130c--