hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Poon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9899) for idempotent operation dups, return the result instead of throwing conflict exception
Date Thu, 09 Mar 2017 18:55:38 GMT

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

Mime
View raw message