[
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487070
]
Srinivasa commented on OPENJPA-203:
-----------------------------------
My initial approach was the same that we could move the responsibility of
setting the lock-level to lockInternal. The only concern that lead me to this
approach was that - if an overriding lockInternal method calls super()
following up with some code that can throw an exception - the lockInternal
override will have to unset the lock in its catch block to unset the value set
by the super call. (Note the current override PessimisticLockManager does not
run into this issue as the super() call is at the end).
So I went with the idea that the lock() is responsible for setting the lock
level, and in the special case of VersionLockManager where its lockInternal
code needs the lock-level set before to avoid infinite recursion - it can
handle the case by setting, later unsetting - keeping the lock-level change
need local.
That being said I dont terribly mind changing to the suggested approach.
> 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.
