db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2107) Move page latching out of the lock manager
Date Thu, 14 Dec 2006 22:13:22 GMT
    [ 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

        

Mime
View raw message