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

Lars Hofhansl commented on HBASE-10126:
---------------------------------------

You're not using HRegion.mutateRowsWithLocks, which was added for this purpose. 
Why?
If this can be done with doMiniBatchMutation alone, we should get rid of 
mutateRowsWithLocks.

The entire batch will not be atomic, only the parts that happen to fall within 
the same region. And without a split policy there is no way of knowing or 
guaranteeing which parts will be updated atomically.

MultiRowMutationEndpoint (coprocessor) checks for that and thus ensures that in 
fact the entire batch can be performed atomically.

If we turn this into a public API there better be no surprises. Your use case 
seems quite special in that you want all rows in a region to be updated 
atomically but you're fine with the batch in its entirety not.

Why can't you use a coprocessor to achieve the same. I'm all for making this a 
public API, but it does expose implementation details to the API (such that 
there are regions, for example).

{code}
-               return server.multi(multi);
+               return server.multi(multi, atomic);
{code}
Better to call server.multi(multi) when atomic is false, so that a new client 
can still work with an old server as long as no atomicity is requested.

This needs more discussion.


> guarantee atomicity of multi-row mutation within a same region from a single 
> HTable.batch
> -----------------------------------------------------------------------------------------
>
>                 Key: HBASE-10126
>                 URL: https://issues.apache.org/jira/browse/HBASE-10126
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Feng Honghua
>            Assignee: Feng Honghua
>         Attachments: HBASE-10126-0.94-v0.patch
>
>
> We use this improvement together with 
> DelimitedKeyPrefixRegionSplitPolicy.java to implement local secondary index 
> without the help of coprocessor.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Reply via email to