Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Sun, 30 Jul 2017 23:31:02 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13090893.1501274497000.47867.1501457462350@Atlassian.JIRA>
In-Reply-To: <JIRA.13090893.1501274497000@Atlassian.JIRA>
References: <JIRA.13090893.1501274497000@Atlassian.JIRA> <JIRA.13090893.1501274497418@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4053) Lock row exclusively when
 necessary for mutable secondary indexing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 30 Jul 2017 23:31:09 -0000


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

Andrew Purtell commented on PHOENIX-4053:
-----------------------------------------

ConcurrentMutationsIT needs an ASF header.

A concern here:
{code}
+        
+        int rowLockWaitDuration = clonedConfig.getInt("hbase.rowlock.wait.duration",
+                DEFAULT_ROWLOCK_WAIT_DURATION);
+        this.lockManager = new LockManager(rowLockWaitDuration);
{code}

is in HBASE-17210 we've plumbed through the client's desired RPC timeout to the rowlock timeout, and if not also done on the Phoenix side in lock management there it will undo it.

> 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_v2.patch, PHOENIX-4053_v3.patch, PHOENIX-4053_v4.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)