[
https://issues.apache.org/jira/browse/PHOENIX-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lokesh Khurana reassigned PHOENIX-7905:
---------------------------------------
Assignee: Lokesh Khurana
> Add transform lock primitive on SYSTEM.MUTEX with narrow caller wiring
> ----------------------------------------------------------------------
>
> Key: PHOENIX-7905
> URL: https://issues.apache.org/jira/browse/PHOENIX-7905
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lokesh Khurana
> Assignee: Lokesh Khurana
> Priority: Major
>
> 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)
