[
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
(v6.4.14#64029)
