[
https://issues.apache.org/jira/browse/HBASE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793509#comment-13793509
]
Vladimir Rodionov commented on HBASE-9751:
------------------------------------------
Still do not understand fully. Read points are necessary to filter out all
changes (deletes, updates) that have been done *after* scanner creation time
and if isolation level is READ_COMMITTED. Read point MUST be the attribute of a
scanner - not a handler thread in this case. Correct?
Sharing the same scanner instance between handler threads is fine if:
A. not at the same time
B. read point is the same (from scanner)
If it is not the case - then it looks like a flaw in the design.
And even in this case there are some situations when scanner is
opened/read/closed in the same thread in one RPC call:
1. Get request
2. Short Scans (most of them)
3. Scanner inside coprocessor call.
> Excessive readpoints checks in StoreFileScanner
> ------------------------------------------------
>
> Key: HBASE-9751
> URL: https://issues.apache.org/jira/browse/HBASE-9751
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.0, 0.94.12, 0.96.0
> Reporter: Vladimir Rodionov
> Assignee: Lars Hofhansl
> Fix For: 0.98.0, 0.94.13, 0.96.1
>
> Attachments: 9751-0.94.txt, 9751-trunk.txt
>
>
> It seems that usage of skipKVsNewerThanReadpoint in StoreFileScanner can be
> greatly reduced or even eliminated all together (HFiles are immutable and no
> new KVs can be inserted after scanner instance is created). The same is true
> for MemStoreScanner which checks readpoint on every next() and seek(). Each
> readpoint check is ThreadLocal.get() and it is quite expensive.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
