[
https://issues.apache.org/jira/browse/HBASE-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628631#comment-15628631
]
Anoop Sam John commented on HBASE-16992:
----------------------------------------
bq.If so, the acquiredRowLocks() can be saved
This do a readLocking so NP right? It will add one more reader counter but is
ok I guess. And as said this can be another RK also in theory. But ideally CP
user should not return any unrelated rk Mutation corresponding to the original
index. (See we will do index matching to get corresponding Mutations). One
use can be while doing local indexing in Phoenix where the index row is related
to the original row and its rk also but not exactly same as the rk of the
original Mutation.
bq.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.
Good. Ya I feel we should enforce that the Mutations should have same
Durability as that of the original Mutation. After all we are merging all cells
together. And ya that recordMutationsWithoutWal() will be a duplicate call
now. We can avoid
cc [~enis]
> 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)
