phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4053) Lock row exclusively when necessary for mutable secondary indexing
Date Mon, 31 Jul 2017 17:06:00 GMT

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

Samarth Jain commented on PHOENIX-4053:
---------------------------------------

[~jamestaylor], 

Regarding your comment here:
{code}
+                  if (!success) {
+                      // We're throwing here, so we won't be locking any more rows. By setting
the
+                      // status to FAILURE, we prevent the attempt to unlock rows we've never
+                      // locked when postBatchMutateIndispensably is executed. We're very
+                      // limited about the state that can be shared between the batch mutate
+                      // coprocessor calls (see HBASE-18482).
+                      // Note that we shouldn't necessarily be throwing here, since we're
+                      // essentially failing the data write because we can't do the locking
+                      // necessary for performing consistent index maintenance. We'd ideally
+                      // want to go through the index failure policy to determine what action
+                      // to perform. We currently cannot ignore this lock failure
+                      for (int j = i; j < miniBatchOp.size(); j++) {
+                          miniBatchOp.setOperationStatus(j,FAILURE);
+                      }
+                  }
{code}
I don't see a throw statement here. My guess is there is some code in HBase which is going
through the operation status array and taking appropriate action? I think it would make sense
for the comment to state that. FWIW, I see callers of region.batchMutate within our Phoenix
co-processors (UngroupedAggregateRegionObserver#commitBatch() and UngroupedAggregateRegionObserver#rebuildIndices)
that don't seem to be looking at the return status. Maybe they should? 



> Lock row exclusively when necessary for mutable secondary indexing
> ------------------------------------------------------------------
>
>                 Key: PHOENIX-4053
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4053
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>         Attachments: PHOENIX-4053_4.x-HBase-0.98_v2.patch, PHOENIX-4053_4.x-HBase-0.98_v3.patch,
PHOENIX-4053-4.x-HBase-0.98_v4.patch, PHOENIX-4053-4.x-HBase-0.98_v6.patch, PHOENIX-4053_v2.patch,
PHOENIX-4053_v3.patch, PHOENIX-4053_v4.patch, PHOENIX-4053_v5.patch, PHOENIX-4053_v6.patch,
PHOENIX-4053_wip.patch
>
>
> From HBase 1.2 on, rows are not exclusively locked when the preBatchMutate call is made
(see HBASE-18474). The mutable secondary index (global and local) depend on this to get a
consistent snapshot of a row between the point when the current row value is looked up, and
when the new row is written, until the mvcc is advanced. Otherwise, a subsequent update to
a row may not see the current row state. Even with pre HBase 1.2 releases, the lock isn't
held long enough for us. We need to hold the locks from the start of the preBatchMutate (when
we read the data table to get the prior row values) until the mvcc is advanced (beginning
of postBatchMutateIndispensably).
> Given the above, it's best if Phoenix manages the row locking itself (mimicing the current
HBase mechanism).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message