> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> > > > Date: February 12, 2007 11:45:52 AM PST > > > To: [EMAIL PROTECTED] > > > Subject: pessimistic locking > > > Reply-To: [EMAIL PROTECTED] > > > > > > 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 > > > [EMAIL PROTECTED] http://db.apache.org/jdo > > > > > > > > > > > >
