[
https://issues.apache.org/jira/browse/HBASE-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635299#comment-15635299
]
Anoop Sam John commented on HBASE-16992:
----------------------------------------
bq.The main point i concern is the cells in one mutation may have different
rows, because we merge the cells returned by CP into original mutation.
Pls note that the merge method merges the cell sets into a single set. There is
no Mutation change happening here. This collection of cells is what treated as
a single unit of write. So IMO there is no breaking of the Row agreement. It
should be ok.
So the issue to be handled here is to avoid the duplicate call to
recordMutationWithoutWal (?) We need to avoid the call before merge op.
Also as said, we dont consider Durability from CP. We will go with same
Durability as that of the corresponding Mutations in batch. Any checks and
fail needed? May be not. Pls add some comments around code that we do this way.
> The usage of mutation from CP is weird.
> ---------------------------------------
>
> Key: HBASE-16992
> URL: https://issues.apache.org/jira/browse/HBASE-16992
> Project: HBase
> Issue Type: Bug
> Reporter: ChiaPing Tsai
>
> {code:title=HRegion#doMiniBatchMutate|borderStyle=solid}
> Mutation cpMutation = cpMutations[j];
> Map<byte[], List<Cell>> cpFamilyMap = cpMutation.getFamilyCellMap();
> checkAndPrepareMutation(cpMutation, replay, cpFamilyMap, now);
> // Acquire row locks. If not, the whole batch will fail.
> acquiredRowLocks.add(getRowLockInternal(cpMutation.getRow(), true));
> if (cpMutation.getDurability() == Durability.SKIP_WAL) {
> recordMutationWithoutWal(cpFamilyMap);
> }
> // Returned mutations from coprocessor correspond to the Mutation at index i.
> We can
> // directly add the cells from those mutations to the familyMaps of this
> mutation.
> mergeFamilyMaps(familyMaps[i], cpFamilyMap); // will get added to the
> memstore later
> {code}
> 1. Does the returned mutation from coprocessor have the same row as the
> corresponded mutation? If so, the acquiredRowLocks() can be saved. If not,
> the corresponded mutation may maintain the cells with different row due to
> mergeFamilyMaps().
> 2. Is returned mutation's durability useful? If so, we should deal with the
> different durabilities before mergeFamilyMaps(). If not, the
> recordMutationWithoutWal can be saved.
> 3. If both the returned mutation and corresponded mutation have
> Durability.SKIP_WAL, the recordMutationWithoutWal() may record the duplicate
> cells due to mergeFamilyMaps().
> Any comment? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
