[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[ 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.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[ 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.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487078
]
Abe White commented on OPENJPA-203:
---
If we don't want the subclasses to have to unset the lock value in case of
exception, another option would be to have lock() delegate to lockInternal for
setting the lock value, but to unset the lock value itself on error:
int oldValue = getLockValue(sm);
try {
lockInternal(...);
} catch (RuntimeException re) {
setLockValue(sm, oldValue);
throw re;
}
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.
