[ http://issues.apache.org/jira/browse/DERBY-2107?page=all ]
Mike Matrigali updated DERBY-2107: ---------------------------------- Dan is absolutely right about the unlatch() call. Once unlatch call is made the page is free to be thrown out of the cache and be replaced by a different page, from possibly a different table, different page size .... Once you call unlatch you have to reload the buffer manager, the problem is that you can't do it in the interfaces you have as the callers still have the old reference. The btree code does this in it's code that manages latch/lock outside of lockmanager. For btree it was necessary as after you gave up latch while waiting on lock the row could move off the original page. For heap rows don't ever move off the page. They can "disappear" in the purge case described above, and in the offline compress case which is handled by a table level lock. > 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, Performance > 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, > derby-2107-1b.diff > > > 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
