Lokesh Khurana created PHOENIX-7905:
---------------------------------------
Summary: Modification lock primitive on SYSTEM.MUTEX with TTL
recovery
Key: PHOENIX-7905
URL: https://issues.apache.org/jira/browse/PHOENIX-7905
Project: Phoenix
Issue Type: Sub-task
Reporter: Lokesh Khurana
Phoenix's OSC framework needs a modification-lock primitive to serialize ALTER
TABLE statements with concurrent transforms (and to gate Gap O's CREATE VIEW
lockout). Without it, two operators ALTERing the same table can race;
TransformMonitorTask can pick up a half-written SYSTEM.TRANSFORM row.
*Decision:* Implement as a SYSTEM.MUTEX-backed lock with SYSCAT-timestamp
check-and-mutate. TTL on the lock row handles stuck-holder recovery
*Implementation:*
* Add {{MODIFICATION_LOCK_TS}} and {{MODIFICATION_LOCK_HOLDER}} columns on
SYSTEM.MUTEX (or equivalent). Lock take = HBase check-and-mutate on
{{MODIFICATION_LOCK_TS}} (set if null OR older than TTL); release =
unconditional delete by holder.
* Initial TTL deliberately large (likely on the order of hours); tune at
code-review time.
* The same primitive backs:
** Gap B's {{CUTOVER_IN_PROGRESS}} state CAS pattern (different lock ID).
** Gap O's CREATE VIEW lockout during transform (different lock ID).
*Acceptance criteria:*
* Concurrent ALTER TABLE on the same logical table serializes correctly (one
succeeds, one waits or fails-fast per policy).
* Stuck lock holder (process death) is auto-released after TTL expires; next
contender acquires.
* IT covers: happy take/release, contention, TTL expiry, take-after-TTL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
