[
https://issues.apache.org/jira/browse/HBASE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859050#comment-13859050
]
Andrew Purtell commented on HBASE-8458:
---------------------------------------
I agree with N that having a class of operations excluded from multi is an API
design issue. We went down this road when the checkAndXXX operations were first
added as special code paths, but they were needed at the time so the changes
were accepted and have remained useful since. However we really should have all
APIs derived from common ancestors that can be combined into a single RPC.
bq. I did look at the other multis when I worked on the client in the 0.96,
but doing a proper work would have cost more than a week of work, so I excluded
it..
This is the crux of the issue.
If we are going to do this we should do it before a 1.0 release adds
expectations on client API compatibility we can sidestep currently.
> Support for batch version of checkAndPut() and checkAndDelete()
> ---------------------------------------------------------------
>
> Key: HBASE-8458
> URL: https://issues.apache.org/jira/browse/HBASE-8458
> Project: HBase
> Issue Type: Improvement
> Components: Client, regionserver
> Affects Versions: 0.95.0
> Reporter: Hari Mankude
>
> The use case is that the user has multiple threads loading hundreds of keys
> into a hbase table. Occasionally there are collisions in the keys being
> uploaded by different threads. So for correctness, it is required to do
> checkAndPut() instead of a put(). However, doing a checkAndPut() rpc for
> every key update is non optimal. It would be good to have a batch version of
> checkAndPut() similar to batch put(). The client can partition the keys on
> region boundaries.
> The jira is NOT looking for any type of cross-row locking or multi-row
> atomicity with checkAndPut()
> Batch version of checkAndDelete() is a similar requirement.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
