From dev-return-10588-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Fri Feb 20 16:13:54 2009 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 40592 invoked from network); 20 Feb 2009 16:13:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Feb 2009 16:13:54 -0000 Received: (qmail 36831 invoked by uid 500); 20 Feb 2009 16:13:54 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 36673 invoked by uid 500); 20 Feb 2009 16:13:53 -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 36662 invoked by uid 99); 20 Feb 2009 16:13:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 08:13:53 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tim.mcconne@gmail.com designates 209.85.221.21 as permitted sender) Received: from [209.85.221.21] (HELO mail-qy0-f21.google.com) (209.85.221.21) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2009 16:13:44 +0000 Received: by qyk14 with SMTP id 14so3995077qyk.9 for ; Fri, 20 Feb 2009 08:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=W5NkP4ZFmjRdE2EBt5F3/n4tFyCjp6Masx0zry1BehM=; b=YbeONivZo4KtkuRgReE94fmUZqCStU3ng6EqhrHTt9IChckTUGoGxpsNR2U+WWy6yf PG4W5ma5u0kbPn70ENGSbWxlA88FfNHuKZeguL6VPYYRD9bmMkvPWfXT/yPYGSuFE3+e EMwUNWtigAcVk/Dwl1ZO/95N5cGUHCQncKEjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=L2u4qiGlHqL9C70DGYiMiDtb/Sv+zRSy5LugUd7y7s7wvSiJFsqe2isN1EVmxmrXEB dUYRRw3aeBZSn3timwX4ifm+S4gb3/2Ukvi5KCCk371MR9QxDN6pFFLGUnMPddWbKIKK ZYP1zSyxmd9faWPEKfPohMFs3THAzPmuOqKyc= Received: by 10.224.2.138 with SMTP id 10mr1618863qaj.299.1235146403469; Fri, 20 Feb 2009 08:13:23 -0800 (PST) Received: from ?9.51.245.56? ([32.97.110.55]) by mx.google.com with ESMTPS id 6sm495183qwk.47.2009.02.20.08.13.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 08:13:22 -0800 (PST) Message-ID: <499ED69A.1000104@gmail.com> Date: Fri, 20 Feb 2009 11:13:14 -0500 From: Tim McConnell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: dev@openjpa.apache.org Subject: Re: Optimistic Locking question References: <499E5096.30700@gmail.com> <89c0c52c0902200712v26f2bd68ocf1df9140f596803@mail.gmail.com> In-Reply-To: <89c0c52c0902200712v26f2bd68ocf1df9140f596803@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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