openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: pessimistic locking
Date Tue, 13 Feb 2007 18:21:49 GMT
Patrick,
Just to clarify...  If we set up OpenJPA in this manner (Optimistic to false
and the Read and Write Lock levels to None), then all transactions would
then be running in Pessimistic mode, right?  That is, we don't have the
means of being more granular with these settings, do we?

Kevin

On 2/12/07, Patrick Linskey <plinskey@bea.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message