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 18:37:09 GMT
> 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?

I'm not sure what you mean about "more granular". First, some context
for the non-SpecJ-aware: to my knowledge, SpecJ allows configuration
changes but not code changes. I do not know the granularity at which
SpecJ allows configuration changes to differ.

The openjpa.Optimistic and read- and write-level settings are defaults
that apply to all EMs created from an EMF. However, these defaults can
be changed in a number of ways. 

1. Theoretically, a developer can pass in different values via the
createEM(Map) call. I don't remember how many options we allow to be
configured in this way, though.

2. A developer can programmatically change the transaction type before
beginning the transaction, via OpenJPA-proprietary APIs.

3. The default read and write lock levels can be changed on-the-fly via
the OpenJPA-proprietary FetchPlan interface. This can be done on a
per-EM or per-Query basis. Of course, a downgrade of lock levels may be
ignored.


So, from a per-transaction / per-operation standpoint, you can get more
granular, but not without some sort of code involved.


> all transactions would
> then be running in Pessimistic mode, right?

With Optimistic=false and a lock level of none, we're not really talking
about pessimistic transactions. IOW, Optimistic=false is not the same as
Pessimistic=true.

In the case at hand, the idea is that SpecJ will use datastore locking
to block resources so that highly-concurrent writes don't step all over
each other. So, the pattern here is that no locking will be done for
most records, and the code will explicitly lock the record that it
intends to change by calling em.lock(em.getReference(...),
LockLevel.WRITE). So, there will be a datastore-side lock on the one
instance queried for, and no others.

If you're wondering about intra-transaction locking, then you could lock
additional instances with more calls to em.lock(), or by setting a
particular query's lock level in its FetchPlan.

Also, it's worth noting that when Optimistic=false, OpenJPA still runs
the optimistic lock checks and increments on instances that use
optimistic locking. This makes it possible to have a hybrid runtime
environment where some transactions use datastore locking and others do
not. The option is possibly not ideally-named.

-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: Kevin Sutter [mailto:kwsutter@gmail.com] 
> Sent: Tuesday, February 13, 2007 10:22 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: pessimistic locking
> 
> 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
View raw message