[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
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.
[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486087
]
Jacek Laskowski commented on OPENJPA-197:
-
Hibernate and TopLink will fail once you get rid of the if statement. It's
because according to the spec (and my understanding) merge should rise
exception when the versioned property is outdated. The spec doesn't say about
any deferred check (at flush or commit time) against a versioned property and
therefore I think it's a bug in OpenJPA.
@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.
[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
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.
[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486091
]
Patrick Linskey commented on OPENJPA-197:
-
Note that there are significant performance impacts to doing the check at
merge() time.
Is there any reason why you need a check to happen at merge() time? Is it
sufficient to just follow the merge() call with a flush()? Alternately, how
about a call to OpenJPAEntityManager.validateChanges()?
@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.
Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
Hibernate and TopLink will fail once you get rid of the if statement. It's because according to the spec (and my understanding) merge should rise exception when the versioned property is outdated. No, the exception can be deferred until flush/commit. Read section 3.2.4.1. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
On Apr 2, 2007, at 11:18 AM, Abe White wrote: 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). Ok. 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. I'd call this a spec inconsistency. Sadly, when the spec talks about the same thing in multiple places, it's a source of human error if different places are inconsistent. You can send a clarification request to the spec feedback alias to confirm this. 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. There's nothing special about the RI and its non-specified behavior. If the RI has a behavior that is not specified, then all that means is that you can write non-portable code with a dependency on the RI, just as you can write non-portable code with a dependency on OpenJPA. By the way, there is similar behavior for persist and delete, wherein deferred writes to the database are legal. Some implementations might flush immediately and detect duplicate/missing database instances but you cannot depend on this behavior either. Craig I wish I could give it a shot with other JPA providers than OpenJPA, TopLink and Hibernate (but would that change anything?). OK, then read the 4th paragraph of section 3.4.2. Also, note the fact that the TCK doesn't test for exception on merge. It doesn't matter how other implementations work, OpenJPA is completely correct according to the spec. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486112
]
Jacek Laskowski commented on OPENJPA-197:
-
Please close the issue with WON'T FIX or alike due to the section in JPA spec -
3.4.2 Version Attributes page 55:
The persistence provider's implementation of the merge operation must examine
the version attribute when an entity is being merged and throw an
OptimisticLockException if it is discovered that
the object being merged is a stale copy of the entity—i.e. that the entity has
been updated since the entity became detached. Depending on the implementation
strategy used, it is possible that this exception may not be thrown until flush
is called or commit time, whichever happens first.
The relevant part is the last sentence. Sorry for bothering.
@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.
