Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 21977 invoked from network); 27 Apr 2007 18:55:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Apr 2007 18:55:43 -0000 Received: (qmail 19110 invoked by uid 500); 27 Apr 2007 18:55:49 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 19083 invoked by uid 500); 27 Apr 2007 18:55:49 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 19074 invoked by uid 99); 27 Apr 2007 18:55:49 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2007 11:55:49 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jason.m.hanna.at.coincident@gmail.com designates 209.85.132.249 as permitted sender) Received: from [209.85.132.249] (HELO an-out-0708.google.com) (209.85.132.249) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Apr 2007 11:55:42 -0700 Received: by an-out-0708.google.com with SMTP id b2so726687ana for ; Fri, 27 Apr 2007 11:55:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FrJS+xCEFLK01n5ATx7SLNAdF/+iCTZy1I+0haaPj3JCgYWTOZmsj36s7qlWmpuit9IpxQ1Xc206T/YFIQ/aw0OPnt7kNbXT2FeIGAz6pqOP1V6Z+iORrC9HAdY2F3jg0WQAsllPgaAHDIrffLHPPEKMpnj1xTDV+0K4k8wp+2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ecnw/hgkV6vmR/0Z/HRJVRaKqosRvjDIIuc1d3t6OZlkuZbwXBho3/+wQWMrVF9xXT/ZjYkn6IZCAbFOtHioVwAerTuvDkwqt9mlXkjo+ZqxNmu24jzRyu+3zRt0nD42iDs1+rO9+ytFIz+a1dv9R0uwVyeXWfYBXKkqrd9adH4= Received: by 10.100.154.13 with SMTP id b13mr2142643ane.1177700120879; Fri, 27 Apr 2007 11:55:20 -0700 (PDT) Received: by 10.100.241.15 with HTTP; Fri, 27 Apr 2007 11:55:20 -0700 (PDT) Message-ID: <8f9e78f00704271155i62561821se9476e6c2cfc39f@mail.gmail.com> Date: Fri, 27 Apr 2007 14:55:20 -0400 From: "Jason Hanna" To: open-jpa-dev@incubator.apache.org Subject: Re: Merge Detached Entity Problem In-Reply-To: <8f9e78f00704271013k3c4fb839lbfd6d13419b1b761@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f9e78f00704271013k3c4fb839lbfd6d13419b1b761@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org An update - I was not using the @Version annotation in my item definition. After updating my class with the annotation and adding additional database column, my original reported problem disappears. My first read of the documentation led me to believe the @Version annotation was a best practice, but not necessary. >From the OpenJPA User's Guide, Section 1.4: ---start Note OpenJPA fully supports version fields, but does not require them for concurrency detection. OpenJPA can maintain surrogate version values or use state comparisons to detect concurrent modifications. See Section 7, " Additional JPA Mappings " in the Reference Guide. ---end I seem to have resolved my immediate issue, but perhaps someone can set me straight on the expected behavior when the @Version annotation is not present. Thanks, -jmh On 4/27/07, Jason Hanna wrote: > Hi All, > > I'm running into a problem developing a web application that utilizes > JSF and JPA. Not sure if my problem is related to an OpenJPA bug, or a > flaw in my approach. I'm hoping you can help. > > In my web application, a user selects an item to "edit" from a table > of all available items. They are then directed to a page containing a > form which allows them to modify the details of the item they selected > (pretty standard web app stuff). > > Upon submission, the backing bean connected to this form invokes the > update method of the item's data access object. The DAO in turn > creates and EntityManager from the EntityManagerFactory, starts a > transaction, merges the detached object, and commits the transaction. > > If any value is modified on the item edit form, the detached object is > merged and successfully committed. That's good. Now for the problem: > > If the detached object is NOT modifed (edit form submitted w/o any > changes) the merge will fail on the EntityManager transaction commit > with the following error: > > <2|true|0.9.5-incubating> > org.apache.openjpa.persistence.RollbackException: Optimistic locking > errors were detected when flushing to the data store. The following > objects may have been concurrently modified in another transaction: > [com.coincident.green.beans.User-com.coincident.green.beans.User-1] > > I've read through the lifecycle management documentation and don't see > why attempting to merge an unchanged detached entity would result in > an exception. > > I could probably detect that no updates were made at my JSF managed > bean and avoid the merge operation altogether, but what happens when > my item references other managed entities and I want to utilize > cascade merge? > > Hoping you all might have some thoughts. Here are a few details about > my environment: > > Sun JDK 1.5.0_06 > Apache Tomcat 5.5.20 > MyFaces 1.1.3 > OpenJPA 0.9.5 (Packaged w/BEA Workship Studio and Kodo) > MySQL 5.0.27 (Community) > > Thanks! Please let me know if you require any more information. > > Regards, > -jmh > > Jason M. Hanna > President/Founder > Coincident, Inc. >