[
https://issues.apache.org/jira/browse/PHOENIX-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804501#comment-16804501
]
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: https://issues.apache.org/jira/browse/PHOENIX-5156
> 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
(v7.6.3#76005)
