[
https://issues.apache.org/jira/browse/HBASE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858632#comment-13858632
]
Lars Hofhansl commented on HBASE-8458:
--------------------------------------
This can actually be done with a coprocessor now, no? All the pieces are in
place (locks, leases, etc). If there's something missing, we should add/expose
that.
If we wanted to add this to the HTable API, we'd have to discuss exact return
value (array of booleans, probably) and behavior under partial failure (maybe
just behave as multi put - checkAndPut are still idempotent so that should work)
> 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)