[jira] Updated: (DERBY-2107) Move page latching out of the lock manager

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ 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