[
https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187680#comment-16187680
]
Anoop Sam John commented on HBASE-18703:
----------------------------------------
Sorry for the delay
Making use of RowProcessor for the mutateRows and so many diff with the CP
calls and complexity.. it is fine to unify and make them simple.
bq.Deprecate RowProcessor and API Region.processRowsWithLocks() that takes
RowProcessor as an argument.
But this point am not sure. So u propose we dont give RowProcessor kind of way
for customized processing? In another issue comment discussion Chia-Ping gives
a use case as below
{quote}
The row locks is a dangerous feature for us, but it is also a powerful tool for
cp user. The use cases I had saw use the write locks to implement
compare-and-update over multi-rows.
1) get write-lock for all required rows (Region#getRowLock)
2) get latest data (Region#get)
3) generate the Puts/Deletes according to the latest data
4) do Put/Delete
It seems to me that removing row locks in 2.0 is fine if we provide more
flexible multi-rows operation in follow-up. I guess Phoenix has similar impl of
compare-and-update.
{quote}
Use has to do multi row compare and based on that do a mutate op on another
row.. I see adding a new API which takes rowsToLock. But here in this issue,
user may have to take write locks on certain rows and read lock on another.
Also has to do a complex compare op on many row:columns. What is the alternate
we can give? I believe RowProcessor was added as a means for doing such things.
So still that is useful.
I believe if we can unify the code paths of processRowsWithLocks and
doMiniBatchMutate() and make the mutateRows NOT to follow the RowProcessor way
of impl, the 1st issue of CP call diff and complexity can be avoided. Also we
can make the RowProcessor to be simpler as in the past with just a pre and post
process and a process() call. May be we can add an impl usage in the examples
module with a use case what is mentioned above.
> 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
>
>
> 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)
