phoenix-dev mailing list archives

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

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

Hudson commented on PHOENIX-4053:
---------------------------------

FAILURE: Integrated in Jenkins build Phoenix-master #1723 (See [https://builds.apache.org/job/Phoenix-master/1723/])
PHOENIX-4053 Lock row exclusively when necessary for mutable secondary (jamestaylor: rev 54d9e1c36c46e7c50c29def08cf866599c7a4e45)
* (add) phoenix-core/src/it/java/org/apache/phoenix/end2end/ConcurrentMutationsIT.java
* (edit) phoenix-core/src/test/java/org/apache/phoenix/util/TestUtil.java
* (add) phoenix-core/src/main/java/org/apache/phoenix/hbase/index/LockManager.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/hbase/index/Indexer.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/hbase/index/builder/IndexBuildManager.java


> 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
>             Fix For: 4.12.0, 4.11.1
>
>         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_v7.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