Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Message-ID: <15166447.1175785892558.JavaMail.jira@brutus>
Date: Thu, 5 Apr 2007 08:11:32 -0700 (PDT)
From: "Abe White (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not
 locking the rows
In-Reply-To: <29527140.1175763452220.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486999 ] 

Abe White commented on OPENJPA-203:
-----------------------------------

Looks good.  Although I think I'd prefer to make lockInternal() responsible for setting the lock level rather than having to set it and unset it so that lock() can set it again... it's just too ugly.  So instead we just remove the setting of the lock level in lock() and make VersionLockManager only unset the lock level in its lockInternal if an exception occurs.  PessimisticLockManager wouldn't have to change (outside of the changes already in your patch) because it delegates to super.lockInternal already, so the lock level would get set appropriately.  

> Pessimistic Lock Manager not locking the rows 
> ----------------------------------------------
>
>                 Key: OPENJPA-203
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-203
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.0, 0.9.6
>         Environment: ran against Oracle
>            Reporter: Srinivasa
>         Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With  pessimistic lock manager multiple EMs are able to modify the same object concurrently.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.