[ 
https://issues.apache.org/jira/browse/HBASE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17069125#comment-17069125
 ] 

Toshihiro Suzuki commented on HBASE-8458:
-----------------------------------------

[~stack] Thank you taking a look at this!

Please find my inline answers below:

> Old clients will work against new servers with this patch across all of their 
> API? checkAndMutate with RM too? Or will checkAndMutate break after this 
> patch goes in?

Yes, old clients will work against new servers with this patch across all of 
their API. And checkAndMutate with RM too.

> New clients will break against servers w/o this patch? For checkAndMutate 
> only?

New clients will break against servers w/o this patch for checkAndMutate with 
RM and mutateRow.

> For rolling upgrade, we'd do servers first? Old clients wouldn't be able to 
> make use of this new facility. We'd then roll out the new clients and they 
> could then use the new batching?

Yes, that's right. For rolling upgrade, we will need to upgrade servers first, 
and then roll out the new clients.

Thanks.


> 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
>            Assignee: Toshihiro Suzuki
>            Priority: Major
>
> 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
(v8.3.4#803005)

Reply via email to