yuqi1129 opened a new pull request, #12184: URL: https://github.com/apache/gravitino/pull/12184
### What changes were proposed in this pull request? Implements optimistic concurrency control (version CAS) for the Gravitino store's entity write paths, so metadata writes are correct under HA without a distributed lock. Two halves: **Alter (update) — version CAS** - Always raise `current_version` on every successful update (metalake/catalog/schema/topic/tag/user/group/role were frozen; table/view/function already did; fileset/policy stay conditional as their version doubles as the version-history pointer). - Slim the `UPDATE ... WHERE` to `id + current_version + deleted_at` for the always-increment entities (drop the fragile full-row / JSON-byte compare); fileset/policy keep the full-row compare. - `model_meta` had no version columns: add `current_version`/`last_version` (mysql/postgresql/h2 base schema + 1.3.0->2.0.0 upgrade scripts, DEFAULT 1), raise them on `updateModel`, and make a model-version add also bump `current_version`. - Roll back dependent (version/relation/audit/changelog) writes when the main CAS loses. **Drop (delete) — version-checked soft-delete** - Add a `current_version` parameter to the direct `softDelete<Entity>By...Id` and check it in the `WHERE` (base + PostgreSQL) for 12 entities: topic, table, fileset, view, function, model, metalake, catalog, user, group, role, schema (non-cascade). Each delete reads the PO then passes its version, so the CAS protects the read->delete window. - Semantics: 0 rows -> `return false`; cascade/relation cleanup only when the row count > 0. - Excluded by design: tag/policy (single atomic by-name delete, no read->delete window, already count-based) and schema's hierarchical cascade (deletes multiple descendant schemas via a name-batch, so a single-version CAS does not apply). ### Why are the changes needed? Today no entity does a clean version CAS: updates froze the version and leaned on a byte-for-byte row compare, and deletes ignored the version entirely. Under HA this cannot reliably detect concurrent writes. Part of #12166. Fix: #12166 ### Does this PR introduce _any_ user-facing change? No REST/API change. A write (update or delete) that loses a concurrent race matches 0 rows and is surfaced through the existing update-failure / delete-returns-false paths. Storage: two additive columns on `model_meta` (with an upgrade script); no data migration. ### How was this patch tested? Unit tests pin post-update version increments and DB-level CAS behavior (stale version -> 0 rows, current -> 1 row + bump) across entities, plus a model test asserting insert=1 -> update=2 -> add-version=3. The full `storage.relational.*` suite passes on H2. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
