I think it's legit. In OpenJPA, to make this work in the intended manner, they should set openjpa.Optimistic to false and both openjpa.ReadLockLevel and openjpa.WriteLockLevel to 'none'.
-Patrick -- Patrick Linskey BEA Systems, Inc. _______________________________________________________________________ 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. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, February 12, 2007 1:51 PM > To: open-jpa-dev@incubator.apache.org > Subject: Fwd: pessimistic locking > > Comments from the experts here? > > Craig > > > Begin forwarded message: > > > From: Scott Oaks <[EMAIL PROTECTED]> > Date: February 12, 2007 11:45:52 AM PST > To: [EMAIL PROTECTED] > Subject: pessimistic locking > Reply-To: [EMAIL PROTECTED] > > The SPEC organization is in the process of developing a > JPA-based > benchmark based on the CMP 2.1 implementation of > SPECjAppServer 2004. > Certain objects used in that benchmark are concurrently > modified by > multiple clients simultaneously; in order to score well on the > benchmark, pessimistic locking must be used on those entities. > Otherwise, the time spent rolling back and retrying the > operation (often > multiple times) is quite excessive. > > Realizing that pessimistic locking in the JPA spec is > non-portable, SPEC > intends to go this route: the highly-contended objects > will be obtained > this way: > > Customer c = em.getReference(Customer.class, 1); > em.lock(c, LockModeType.WRITE); > > And have the appserver vendor configure (though > deployment descriptors > or something else that doesn't modify the code) the > locks obtained that > way to be pessimistic locks. They have checked several JPA > implementations, all of whom say that they will be able > to support such > a feature (including, apparently, Toplink, though > AFAIK, that doesn't > apply to the subset of toplink in glassfish). > > This is a feature we would need quite soon; preferably > in 9.1 or at > least in an update soon after. What is the feasibility > of doing so? > > -Scott > > > Craig Russell > DB PMC > [EMAIL PROTECTED] http://db.apache.org/jdo > > >
