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