[
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486089
]
Jacek Laskowski commented on OPENJPA-197:
-----------------------------------------
As I'm unable to write to the dev mailing list I'm responding to Abe White's
comment here that reads "No, the exception can be deferred until flush/commit.
Read section 3.2.4.1."
The spec says in 3.2.4.1 p. 52: Any Version columns used by the entity must be
checked by the persistence runtime implementation during the merge operation
and/or at flush or commit time.
So, one could agree with Abe (the and/or is the key).
Reading about it further, the spec says in 9.1.17 p. 178: "The version is used
to ensure integrity when performing the merge operation and for optimistic
concurrency control." and there's nothing about flush/commit time.
Also, verifying it against RI (which is alas TopLink Essentials) leads to the
same conclusion and it seems that it's only OpenJPA who thinks differently. I
wish I could give it a shot with other JPA providers than OpenJPA, TopLink and
Hibernate (but would that change anything?).
> @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.
