Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <28001381.1166134402314.JavaMail.jira@brutus>
Date: Thu, 14 Dec 2006 14:13:22 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2107) Move page latching out of the lock
 manager
In-Reply-To: <5315982.1164184022042.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-2107?page=comments#action_12458623 ] 
            
Daniel John Debrunner commented on DERBY-2107:
----------------------------------------------

This is how the page latching currently works in the case when the lock manager releases its latch:

Page page = ContainerHandle.getPage(long)
     results in a call to FileContainer.getPage(...)
     - page is found in the cache and kept (ie. usage count in the cache will be bumped)
     - page is latched
         - BasePage.lockEvent() is called  to assign page ownership

    at this point the page is held in the cache and is latched, ContainerHandle.getPage states Page reference will remain valid until unlatch() is called. Note that multiple threads can execute this code concurrently, all will have the same valid reference to the Page, one will have it latched, the others will be queued in the lock manager waiting for the latch to be released.

LockingPolicy.lockRecordForRead() called to get a row lock passing the Page's latch, assume the lock can not be obtained.
   - Page's latch will be released
     - BasePage.unlockEvent() is called to clear page ownership
   - caller will wait for row lock
      at this point the caller still has not returned the Page object to the cache, so from the cache's point of view the
      Page is still in use and so cannot be re-used with another identity.
   - next waiter is be granted the Page latch and continue their work, ie. their  ContainerHandle.getPage(long) returns with the same valid Page reference.

   - at some point the caller gets its row lock and then attempts to get the latch, queuing behind any other waiters
   - once the latch is granted (following the row lock) the lockRecordForRead() call returns
       BasePage.lockEvent() is called to assign page ownership

Caller reads and/or modifies page

Page.unlatch() is called to indicate the caller is finished with the page
   - page is unlatched
   - BasePage.unlockEvent()  is called to clear page ownership
   - Page is released from the cache (ie. usage count decremented)

At this point in time the caller cannot trust the Page reference any more, since its usage count in the cache could have dropped to zero and some other thread could have replaced it.


> 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