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 thisby email and then delete it.-----Original Message----- From: Abe White [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
