phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5156) Consistent Mutable Global Indexes for Non-Transactional Tables
Date Fri, 29 Mar 2019 01:19:00 GMT


Kadir OZDEMIR commented on PHOENIX-5156:

The existing implementation has a flaw in it by releasing Phoenix row locks and letting the
index updates happen without holding the row locks. This allows concurrent index updates on
the same row to get reordered. Since Phoenix Tables can be configured with one row version
(which is the typical case), this will cause data corruption. Also, the HBase time granularity
is only millisecond. We cannot rely on them either for the tables with multiple row versions. PHOENIX-5156.master.005.patch
makes the index and data table updates (i.e., the first two phases of the write operation)
while holding the row locks. It implements the row locks using tryLock with timeout where
the timeout value is small, 200ms, just enough time to let in-progress index updates to complete
in most of the cases. If a row lock cannot be acquired, then it releases all the row locks
acquired in the current batch and return IOException to the client. (Note the current implementation
actually uses trylock with a large timeout value and but do not handle lock failure). This
will cause the client to retry the batch. Since concurrent updates to the same row is not
a very high runner use case in Phoenix, this will be an acceptable solution to prevent deadlocks
due to blocked RCP threads.

> Consistent Mutable Global Indexes for Non-Transactional Tables
> --------------------------------------------------------------
>                 Key: PHOENIX-5156
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.13.0, 4.14.0, 5.0.0, 4.14.1
>            Reporter: Kadir OZDEMIR
>            Assignee: Kadir OZDEMIR
>            Priority: Major
>         Attachments: PHOENIX-5156.master.001.patch, PHOENIX-5156.master.002.patch, PHOENIX-5156.master.003.patch,
PHOENIX-5156.master.004.patch, PHOENIX-5156.master.005.patch
>          Time Spent: 5h 40m
>  Remaining Estimate: 0h
> Without transactional tables, the mutable global indexes can get easily out of sync with
their data tables in Phoenix. Transactional tables require a separate transaction manager,
have some restrictions and performance penalties. This issue is to have consistent mutable
global indexes without the need for using transactional tables.

This message was sent by Atlassian JIRA

View raw message