[jira] Created: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
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.6, 0.9.0 Environment: ran against Oracle Reporter: Srinivasa 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] Resolved: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srinivasa resolved OPENJPA-175. --- Resolution: Fixed Fix Version/s: 0.9.7 Eager selects by PagingResultObjectProvider may not use the FetchBatchSize -- Key: OPENJPA-175 URL: https://issues.apache.org/jira/browse/OPENJPA-175 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Srinivasa Fix For: 0.9.7 Attachments: InExpression-Diff.txt, OPENJPA-175-patch.txt, OPENJPA-175-patch.txt The PagingResultObjectProvider during initialization does checks to determine the appropriate pageSize. While this logic caps the size to 50 and addresses determining an appropriate page size, it doesn't always conform to the set batch size. For example with the size being 1000 and FetchBatchSize set to say 500, the page size is determined to be 50 resulting in eager selects happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srinivasa updated OPENJPA-175: -- 1 - Yes, was planning to do it as a separate JIRA given that it directly does not concern the issue raised here, however I will include it here since we are introducing the in-clause limit in the DBDictionary for this fix. 2 - Looks fine to me, except for the minor issue that in the (size = batch * 2) case we will not be adhering to the FetchBatchSize for pageSize in that the first in-clause query will be for lesser than the FetchBatchSize number of entries, however we will still endup running the same number of in-clause queries - 2. Eager selects by PagingResultObjectProvider may not use the FetchBatchSize -- Key: OPENJPA-175 URL: https://issues.apache.org/jira/browse/OPENJPA-175 Project: OpenJPA Issue Type: Bug Affects Versions: 0.9.0, 0.9.6 Reporter: Srinivasa Attachments: OPENJPA-175-patch.txt, OPENJPA-175-patch.txt The PagingResultObjectProvider during initialization does checks to determine the appropriate pageSize. While this logic caps the size to 50 and addresses determining an appropriate page size, it doesn't always conform to the set batch size. For example with the size being 1000 and FetchBatchSize set to say 500, the page size is determined to be 50 resulting in eager selects happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
