hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
Date Fri, 06 Oct 2017 06:11:02 GMT

    [ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194196#comment-16194196

Anoop Sam John commented on HBASE-18703:

bq.Regarding giving user an option to specify read or write lock, depending on use case this
can be implemented in future. Currently I am trying retain functionality with single code
path. Most use case need exclusive/ write locks on multiple rows. Do you have any use case
for which shared lock on multiple rows is enough?
Not directly..  As per what [~chia7712] said, the RowProcessor was writing one row based on
a read and condition check on some other rows.  So I believe, in such cases, users might be
taking write lock on those rows which has to be evaluated and read lock on the one which has
to be written data to.  Its fine we can check that later.
In this patch, the big part is the (wrt #lines change) is the refactoring of the doMiniBatchMuatate()
method by extracting some private methods.  May be that itself u can do as a separate jira
as that will need careful eye.  And then go with unify the this with the processRowsWithLock

> Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
> --------------------------------------------------------------------------------------
>                 Key: HBASE-18703
>                 URL: https://issues.apache.org/jira/browse/HBASE-18703
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Coprocessors
>            Reporter: Duo Zhang
>            Assignee: Umesh Agashe
>            Priority: Critical
>             Fix For: 2.0.0-alpha-4
>         Attachments: hbase-18703.master.001.patch, hbase-18703.master.002.patch, hbase-18703.master.003.patch,
hbase-18703.master.004.patch, hbase-18703.master.005.patch, hbase-18703.master.005.patch,
hbase-18703.master.005.patch, hbase-18703.master.006.patch, hbase-18703.master.007.patch
> In doMiniBatchMutate, the preBatchMutate is called before building WAL, but in processRowsWithLocks,
we suggest the RowProcessor implementation to build WAL in process  method, which is ahead
of preBatchMutate.
> If a CP modifies the mutations, especially if it removes some cells from the mutations,
then the behavior of processRowsWithLocks is broken. The changes applied to memstore and WAL
will be different. And there is no way to remove entries from a WALEdit through CP. 

This message was sent by Atlassian JIRA

View raw message