You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/02/12 22:50:43 UTC
Fwd: pessimistic locking
Comments from the experts here?
Craig
Begin forwarded message:
> From: Scott Oaks <Sc...@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
Re: pessimistic locking
Posted by Abe White <aw...@bea.com>.
First, I want to point out that I was wrong about needing to set a
lock level in code during an optimistic transaction. So actually for
us to run the benchmark, the only necessary setting is:
openjpa.LockManager: pessimistic
Contrary to what Patrick said and I backed up, we don't need to set
Optimistic to false or set any lock levels. The defaults will work
correctly to avoid locking objects other than those explicitly locked
with EM.lock(), and with the above lock manager those explicitly-
locked objects will get database locks. This seems to me to be
exactly how it should be.
> Hmm. It would seem that the LockManager should default to pessimistic
> when Optimistic=false. Any reason why this is not the case?
With respect to object locking, Optimistic=false just means that
objects are locked automatically at the configured lock levels when
read/written. I don't think that should affect what it means to
"lock" an object, which is the purview of the LockManager.
_______________________________________________________________________
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.
Re: pessimistic locking
Posted by Craig L Russell <Cr...@Sun.COM>.
This benchmark runs best with a combination of optimistic locking
(most cases) and pessimistic locking (some specific uses identified
explicitly in the code).
Where concurrency is low, an optimistic approach works well. In
specific cases, optimistic results in bad performance due to the
number of rollbacks due to failed optimistic transactions. When these
transactions are run in pessimistic mode, competing transactions
queue up behind the first transaction on a specific row, and they all
succeed.
What SPEC is attempting to do is to figure out a way of coding this
behavior for the entities that need the pessimistic behavior. What
OpenJPA will need to do is to implement the pessimistic behavior
given these clues in the code.
Craig
On Feb 13, 2007, at 11:02 AM, Patrick Linskey wrote:
>> We'd also have to set the LockManager property to pessimistic to get
>> database locks.
>
> Hmm. It would seem that the LockManager should default to pessimistic
> when Optimistic=false. Any reason why this is not the case?
>
> -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: Abe White [mailto:awhite@bea.com]
>> Sent: Tuesday, February 13, 2007 10:59 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Re: pessimistic locking
>>
>> We'd also have to set the LockManager property to pessimistic to get
>> database locks. And just to build on what Patrick is saying:
>> OpenJPA
>> can do locking within optimistic transactions on individual
>> instances, but you have to set a lock level on the FetchPlan
>> in code,
>> which I don't think we can do in this benchmark.
>> ______________________________________________________________
>> _________
>> 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.
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: pessimistic locking
Posted by Patrick Linskey <pl...@bea.com>.
> We'd also have to set the LockManager property to pessimistic to get
> database locks.
Hmm. It would seem that the LockManager should default to pessimistic
when Optimistic=false. Any reason why this is not the case?
-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: Abe White [mailto:awhite@bea.com]
> Sent: Tuesday, February 13, 2007 10:59 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: pessimistic locking
>
> We'd also have to set the LockManager property to pessimistic to get
> database locks. And just to build on what Patrick is saying:
> OpenJPA
> can do locking within optimistic transactions on individual
> instances, but you have to set a lock level on the FetchPlan
> in code,
> which I don't think we can do in this benchmark.
> ______________________________________________________________
> _________
> 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.
>
Re: pessimistic locking
Posted by Abe White <aw...@bea.com>.
We'd also have to set the LockManager property to pessimistic to get
database locks. And just to build on what Patrick is saying: OpenJPA
can do locking within optimistic transactions on individual
instances, but you have to set a lock level on the FetchPlan in code,
which I don't think we can do in this benchmark.
_______________________________________________________________________
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.
RE: pessimistic locking
Posted by Patrick Linskey <pl...@bea.com>.
> 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 <pl...@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 <Sc...@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
> > >
> > >
> > >
> >
>
Re: pessimistic locking
Posted by Kevin Sutter <kw...@gmail.com>.
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 <pl...@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 <Sc...@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
> >
> >
> >
>
RE: pessimistic locking
Posted by Patrick Linskey <pl...@bea.com>.
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 <Sc...@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
>
>
>