openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
Date Mon, 02 Apr 2007 19:54:27 GMT

On Apr 2, 2007, at 11:18 AM, Abe White wrote:

>> The spec says in 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.

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.


>> 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
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message