[
https://issues.apache.org/jira/browse/PHOENIX-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095006#comment-15095006
]
Poorna Chandra commented on PHOENIX-2478:
-----------------------------------------
bq. Poorna Chandra - would be much appreciated if you could review this, in
particular the MutationState.commitWriteFence() and
MutationState.addReadFence() to make sure I'm using the APIs correctly.
The usage of Visibility Fence in PHOENIX-2478_v4.patch looks fine to me. Just
one question - what happens when fence await throws {{TimeoutException}}? Is
the index build aborted?
bq. Minor nit: it'd be nice if VisibilityFence.prepareWait() didn't start a new
transaction as that's not necessary in our case.
Are you saying that {{VisibilityFence.prepareWait()}} can use an existing
transaction started by the calling code? If so, caller will have to take over
handling re-tries, right?
bq. Also, it feels like the VisibilityFence feature would benefit from having
something like the ability to do an autonomous transaction to establish the
WriteFence. We really want to add a write barrier at the next possible non
conflicting timestamp, something that seems like would be possible with a new
TransactionManager API.
I agree. Filed https://issues.cask.co/browse/TEPHRA-166 and
https://issues.cask.co/browse/TEPHRA-167 for this.
> Rows committed in transaction overlapping index creation are not populated
> --------------------------------------------------------------------------
>
> Key: PHOENIX-2478
> URL: https://issues.apache.org/jira/browse/PHOENIX-2478
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2478.patch, PHOENIX-2478_v2.patch,
> PHOENIX-2478_v3.patch, PHOENIX-2478_v4.patch
>
>
> For a reproducible case, see IndexIT.testCreateIndexAfterUpsertStarted() and
> the associated FIXME comments for PHOENIX-2446.
> The case that is failing is when a commit starts before an index exists, but
> commits after the index build is completed. For transactional data, this is
> problematic because the index gets a timestamp after the commit of the data
> table mutation and thus these mutations won't be seen during the commit.
> Also, when the index is being built, the data hasn't yet been committed and
> thus won't be part of the initial index build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
