[
https://issues.apache.org/jira/browse/PHOENIX-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816704#comment-16816704
]
Lars Hofhansl commented on PHOENIX-5156:
----------------------------------------
I skimmed the patch. Looks good! I like the structure, at the high level it's
easy to understand - even though it's complex stuff, so that's pretty coll.
Haven't done a detailed review, though.
The 200ms are interesting. Just so I understand; what would be the implication
to set this 0 (i.e. fail immediately when the lock is already acquired by
someone else)?
As I understand it you pick 200ms as a reasonable middle between not waiting
too long, but at the same time wait long enough to reasonably wait out a
concurrent index update...?
As we have to guess, perhaps it's better to try acquiring the lock and fail
immediately... just asking :)
> 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,
> PHOENIX-5156.master.006.patch, PHOENIX-5156.master.007.patch
>
> Time Spent: 8h
> 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)
