openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: pessimistic locking
Date Tue, 13 Feb 2007 05:47:24 GMT
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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
> 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 <Scott.Oaks@Sun.COM>
> 	Date: February 12, 2007 11:45:52 AM PST
> 	To: persistence@glassfish.dev.java.net
> 	Subject: pessimistic locking
> 	Reply-To: persistence@glassfish.dev.java.net
> 
> 	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
> clr@apache.org http://db.apache.org/jdo
> 
> 
> 

Mime
View raw message