[
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.
