Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 98905 invoked from network); 2 Apr 2007 16:45:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Apr 2007 16:45:53 -0000 Received: (qmail 64495 invoked by uid 500); 2 Apr 2007 16:46:01 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 64367 invoked by uid 500); 2 Apr 2007 16:46:00 -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 64349 invoked by uid 99); 2 Apr 2007 16:46:00 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 09:46:00 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 09:45:52 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4A98571403D for ; Mon, 2 Apr 2007 09:45:32 -0700 (PDT) Message-ID: <4850496.1175532332261.JavaMail.jira@brutus> Date: Mon, 2 Apr 2007 09:45:32 -0700 (PDT) From: "Patrick Linskey (JIRA)" To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation In-Reply-To: <12514812.1175499692850.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486065 ] Patrick Linskey commented on OPENJPA-197: ----------------------------------------- I'm a bit confused. Where did Hibernate and Toplink fail? The only merge() call that I see is guarded by a check that should fail for any non-OpenJPA implementation. Also, do you see any difference in behavior if you perform the em.merge() call inside the transaction? Finally, and you test case seems to handle this properly, my interpretation of the spec is that it does not require that the optimistic lock check happen during merge() -- it can happen at a later time instead. It should fail during your em.flush() call at the latest, however. > @Version property doesn't ensure integrity when performing the merge operation > ------------------------------------------------------------------------------ > > Key: OPENJPA-197 > URL: https://issues.apache.org/jira/browse/OPENJPA-197 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Affects Versions: 0.9.7 > Reporter: Jacek Laskowski > > See the simple test case: > { > Query query = em.createQuery("SELECT o FROM Osoba o WHERE o.imie = 'Jacek' AND o.nazwisko = 'Laskowski'"); > final Osoba osoba = (Osoba) query.getSingleResult(); > final Long numerOsoby = osoba.getNumer(); // numer is the pk > long wersja = osoba.getWersja(); // wersja is a versioned property > { > EntityTransaction tx = em.getTransaction(); > tx.begin(); > Osoba osobaWersja0 = em.find(Osoba.class, numerOsoby); > assert osobaWersja0.getWersja() == wersja; > osobaWersja0.setImie("change"); > em.flush(); > wersja++; > assert osobaWersja0.getWersja() == wersja; > tx.commit(); > assert osobaWersja0.getWersja() == wersja; > em.refresh(osobaWersja0); > assert osobaWersja0.getWersja() == wersja; > } > { > em.clear(); // osoba is now detached > final String noweImie = "Yet another name change"; > osoba.setImie(noweImie); > EntityTransaction tx = em.getTransaction(); > tx.begin(); > Osoba osobaWersja1 = em.find(Osoba.class, numerOsoby); > osobaWersja1.setImie("and another"); > tx.commit(); // change is on its way to database > wersja++; > assert osobaWersja1.getWersja() == wersja; > assert osobaWersja1.getWersja() != osoba.getWersja(); > if (em.getClass().getCanonicalName().equals("org.apache.openjpa.persistence.EntityManagerImpl")) { > Osoba osobaPoMerge = em.merge(osoba); > assert osobaPoMerge.getImie().equals(osoba.getImie()); > assert osobaPoMerge.getImie().equals(noweImie); > em.getTransaction().begin(); > try { > em.flush(); > assert false; > } catch (/* OptimisticLock */Exception oczekiwano) { > em.getTransaction().rollback(); > } > } > } > } > It works fine with Apache OpenJPA 0.9.7-SNAPSHOT with the sources on the past Friday. Hibernate EntityManager 3.3.1 and TopLink Essentials 2.0 BUILD 40 throw exception as the detached entity is merged to em. According to the spec 9.1.17 Version Annotation p. 178 (and the javadoc - http://java.sun.com/javaee/5/docs/api/javax/persistence/Version.html - too): > The Version annotation specifies the version field or property of an entity class that serves as its optimistic lock value. The version is used to ensure integrity when performing the merge operation and for optimistic concurrency control. > So, I think that it's a bug in OpenJPA. > BTW, I'm still unable to send emails to open-jpa-dev. Who should I contact to in order to fix it? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.