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!
