[
https://issues.apache.org/jira/browse/HBASE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15903619#comment-15903619
]
Vincent Poon commented on HBASE-9899:
-------------------------------------
[~zghaobac] I have a question about this piece of code:
{code}
synchronized (scannerReadPoints) {
if (mvccReadPoint > 0) {
this.readPt = mvccReadPoint;
} else if (nonce == HConstants.NO_NONCE || rsServices == null
|| rsServices.getNonceManager() == null) {
this.readPt = getReadPoint(isolationLevel);
} else {
this.readPt =
rsServices.getNonceManager().getMvccFromOperationContext(nonceGroup, nonce);
}
scannerReadPoints.put(this, this.readPt);
}
{code}
If we get the readPt from the nonce, should we be adding it to the
scannerReadPoints map ?
The getSmallestReadPoint could go backwards in that case, which doesn't seem
correct?
> for idempotent operation dups, return the result instead of throwing conflict
> exception
> ---------------------------------------------------------------------------------------
>
> Key: HBASE-9899
> URL: https://issues.apache.org/jira/browse/HBASE-9899
> Project: HBase
> Issue Type: Improvement
> Reporter: Sergey Shelukhin
> Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-9899-addendum.patch, HBASE-9899-branch-1.patch,
> HBASE-9899-branch-1.patch, HBASE-9899-branch-1.patch, HBASE-9899-v1.patch,
> HBASE-9899-v2.patch, HBASE-9899-v3.patch, HBASE-9899-v3.patch,
> HBASE-9899-v4.patch, HBASE-9899-v4.patch
>
>
> After HBASE-3787, we could store mvcc in operation context, and use it to
> convert the modification request into read on dups instead of throwing
> OperationConflictException.
> MVCC tracking will have to be aware of such MVCC numbers present. Given that
> scanners are usually relatively short-lived, that would prevent low watermark
> from advancing for quite a bit more time
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
