db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2107) Move page latching out of the lock manager
Date Thu, 14 Dec 2006 21:26:22 GMT
    [ http://issues.apache.org/jira/browse/DERBY-2107?page=comments#action_12458608 ] 
            
Mike Matrigali commented on DERBY-2107:
---------------------------------------

I am reviewing the changes, and do agree with Dan's comments.  Have you thought about the
implecations of order change?  I am 
trying to think if it is a problem.  So far what I am looking at is:

1) With your new implementation a waiting lock now requires 2 trips to the lock manager rather
than the previous 1 trip.
      This was one of the reasons to put latching in the lock manager in the first place,
so that the queuing of the waiting
       lock could be handled once rather than twice.

2) I believe existing implementation the logic for a lock that waits is something like:
     o get exclusive access to lock manager
     o queue waiting lock while holding latch
     o release latch
     o release exclusive access to lock manager
     o wait for grant of lock
     o reclaim latch

     new order is 
     o release latch
     o get exclusive access to lock manager
     o queue waiting lock  WITHOUT latch
     o release exclusive access to lock manager
     o wait for grant of lock
     o reclaim latch


The case I am trying to work out in my mind is the space reclamation thread.  It gets latches
on pages and 
loops through rows requesting zero duration locks to see if it can purge a row from a page.
 In the first case
the row we are requesting a lock on will never be purged as it is not possible for the reclaim
space thread to
get a latch on a the page and purge the row we are waiting for a lock on (the lock request
for an update lock
will fail because of our wait).  In the second case It can sneak in between the release of
the latch and queue
of the waiting lock.

It might not be good that the system depends on this behavior, but at this point I don't know
how much or if 
other code would need to change to support this lock/latch behavior change.  i


> 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