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 Fwd: pessimistic locking
Date Mon, 12 Feb 2007 21:50:43 GMT
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