[ http://issues.apache.org/jira/browse/DERBY-2107?page=all ]
Knut Anders Hatlen updated DERBY-2107: -------------------------------------- Attachment: derby-2107-1a.diff derby-2107-1a.stat Here's a first patch (derby-2107-1a.diff) which implements latching locally in the page objects. Description of the changes: - BasePage.java: - removed all traces of Latch and Lockable - setExclusive() and setExclusiveNoWait() now set the variables that the page is locked (owner and preLatch) directly, instead of going through the lock manager. wait() and notifyAll() are used to coordinate with releaseExclusive(). The rest of the patch affects code that is only called from the unit tests for store. I think this is too much complexity for code that is never used outside the tests, but I'm just trying to preserve the old behaviour for now. - LockingPolicy.java: - the lockRecordForRead() and lockRecordForWrite() methods that took a Latch object was changed to take a Transaction object, a Page object and a ContainerHandle object. This was needed in order to be able to unlatch the latched page in case a row lock couldn't be obtained immediately. - NoLocking.java, RowLocking1.java: - change the signatures as in LockingPolicy. No implementation changes needed. - RowLocking2.java, RowLocking3.java: - change the signatures as in LockingPolicy. - instead of calling the LockFactory.lockObject() method which took a Latch parameter, the logic needed to be inlined. First try to get a row lock without waiting. If it couldn't be obtained immediately, unlatch the page, wait for the lock, and re-latch the page when the lock has been obtained. - Page.java (interface) and BasePage.java (implementation): - added new method Page.latch(ContainerHandle) (which only forwards the call to the protected setExclusive() method) which was needed for the RowLocking* classes to be able to re-latch the page. (Page already has an unlatch() method.) I have run derbyall and the JUnit tests successfully. I sometimes see an error in lang/compressTable.sql, but the same diff has been seen in the nightlies too (http://dbtg.thresher.com/derby/test/trunk15/jvm1.5/testing/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/476241-derbylang_diff.txt). However, I do see it more frequently with the patch, probably because of changes in the timing. This patch does not address deadlock detection issues, or timeout when the latch cannot be obtained. I think those issues would be better to address in follow-up patches (incremental development, right?). Reviews and comments would be greatly appreciated! Thanks. > Move page latching out of the lock manager > ------------------------------------------ > > Key: DERBY-2107 > URL: http://issues.apache.org/jira/browse/DERBY-2107 > Project: Derby > Issue Type: Improvement > Components: Store, Services > Affects Versions: 10.3.0.0 > Reporter: Knut Anders Hatlen > Assigned To: Knut Anders Hatlen > Priority: Minor > Attachments: derby-2107-1a.diff, derby-2107-1a.stat > > > Latching of pages could be done more efficiently locally in store than in the > lock manager. See the discussion here: > http://thread.gmane.org/gmane.comp.apache.db.derby.devel/33135 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira