Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Fri, 14 Apr 2017 21:50:41 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13064150.1492205984000.287582.1492206641855@Atlassian.JIRA>
In-Reply-To: <JIRA.13064150.1492205984000@Atlassian.JIRA>
References: <JIRA.13064150.1492205984000@Atlassian.JIRA> <JIRA.13064150.1492205984764@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-3790) Execute cross region index
 maintenance calls outside of row lock when WAL edits are disabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 14 Apr 2017 21:50:48 -0000


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

Andrew Purtell commented on PHOENIX-3790:
-----------------------------------------

[~giacomotaylor] [~gjacoby] Wouldn't it be fair to say if there is an index defined on a Phoenix table then a mutation with durability of SKIP_WAL can just be ignored? The Durability thing is just a hint, that WAL entries are not _required_.  If there are indexes, we could require them nonetheless. Something to think about. 

> Execute cross region index maintenance calls outside of row lock when WAL edits are disabled
> --------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3790
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3790
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>
> A corner case related to PHOENIX-3789. Non transactional, mutable secondary index maintenance relies on the the WAL edit as state so that the actual index writes can be done later. When WAL edits are disabled, the writes to the index table are done in the preBatchMutation while the row locks are still held which should be avoided.
> This can be fixed by either leveraging a way of passing state between coprocessor hooks (which I'm not sure exists) or through thread locals as a last resort.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)