[
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
