[
https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16190785#comment-16190785
]
Anoop Sam John commented on HBASE-18703:
----------------------------------------
bq.processRowsWithLocks() currently, takes write lock on all user specified
rowsToLock
In case of RowMutations usage of this processRowsWithLocks , we might not need
write locks? Ya I just now noticed how the atomic boolean is been used in the
patch. Can we avoid taking write locks always? Using some way define whether
R/W locks needed. Just trying to make it general by asking more Qs :-)
bq.from inside RowProcessor hooks user can call Region.getRowLock() API. I
believe this is true for coprocessors as well.
If we can make the processRowsWithLocks API to be generic enough which can work
for all possible RowProcessor (And so deprecate that), we can remove the
getRowLock() from Region itself. That would be ideal.
bq.coprocessors can be used for all custom processing that RowProcessors are
used for. I do not have any data about how many users are using RowProcessors.
Yes. For the custom compare logic, prePut() CP can be used and based on the
result, we can allow/bypass the put op.
May be we need split these into diff jiras.
> 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
>
>
> 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)
