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] Updated: (DERBY-2878) Scan protection handle could be cached in BasePage
Date Thu, 28 Jun 2007 18:14:04 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-2878:
----------------------------------


I reviewed this change and it looks good to me, and the approach also seems good. 

Not really part of this change, but did spend some time verifying that fillInIdenity was never
called unless initialize() had been 
called first.  It would be very bad if this got called but the old cached record handle got
left around.  If it were me I would probably
add an extra assert there.   And maybe add asserts somewhere verifying that the record handle
is the right recordhandle.  I think
the current code is right, the asserts are to catch future changes.  A bug in this area is
going to really hard to track down as we just
will be locking the wrong object so no obvious exceptions, just a mysterious timing problems
with concurrent scans in a busy 
system.

> Scan protection handle could be cached in BasePage
> --------------------------------------------------
>
>                 Key: DERBY-2878
>                 URL: https://issues.apache.org/jira/browse/DERBY-2878
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Store
>    Affects Versions: 10.4.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-2878-1.diff, derby-2878-1.stat
>
>
> Each time a leaf node in a B-tree is visited in an index scan, a scan protection row
is locked and unlocked. Both the lock operation and the unlock operation will allocate a new
RecordId object representing the scan protection row (the unlock operation additionally allocates
a PageKey object for the RecordId). Since the scan protection handle created will be identical
(seen from equals()) each time it is created for a page, it would make sense to cache it in
BasePage. Then we only need to allocate the protection handle for a page once for as long
as it stays in the page cache. This would save three object allocations per single-record
lookup via index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message