[
https://issues.apache.org/jira/browse/PHOENIX-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2478:
----------------------------------
Attachment: PHOENIX-2478_v4.patch
Updated patch based on changes to VisibilityFence implementation in Tephra.
[~poornachandra] - 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. Minor
nit: it'd be nice if VisibilityFence.prepareWait() didn't start a new
transaction as that's not necessary in our case. 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.
> 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)
