yuqi1129 opened a new pull request, #13198: URL: https://github.com/apache/gravitino/pull/13198
### What changes were proposed in this pull request? On external-backed paths the store write used to resolve its target by name **after** the external call, so a version CAS that was correct for the row it read could still hit a table re-created under the same name. **Store API** - `EntityVersion` (id + store version) and `EntityStore.getVersion(ident, type)`, which always reads through to the backend. - `EntityStore.delete(ident, type[, cascade], EntityVersion expected)`: `TableMetaService`, `SchemaMetaService`, `TopicMetaService`, `ViewMetaService` and `FunctionMetaService` compare `(id, version)` of the row under the name with the expectation *before* their existing version-CAS delete and throw `OptimisticLockException` on a mismatch, writing nothing. `JDBCBackend` records the drop in the entity change log exactly as the unconditional delete does. **Dispatchers** (`OperationDispatcher`, table, schema, topic, view) - Drop/purge read the registration with `observeRegistration()` before the external call and delete it with `deleteObservedRegistration()` afterwards. A registration that changed in between is left in place and the conflict is reported (same contract as today: `OptimisticLockException` propagates from drop), so a newer incarnation and its owner/tags/policies are never deleted under the old drop. - `requireEntityId(expectedId, updater)` wraps every external-backed `store.update` updater, so an id mismatch aborts inside the store transaction before version, columns or relations move; the post-write id check in `operateOnEntity` is now only a log. ### Why are the changes needed? ``` A: external drop(t) succeeds B: creates a new t, registers it A: store.delete(t) reads the row now under t -> CAS passes -> B's registration and attachments are gone ``` TreeLock hides this on one server; under HA it is reachable today. The same window existed for `alterTable` on a re-created table. Fix: #13172 ### Does this PR introduce _any_ user-facing change? No REST changes. A drop whose registration changed concurrently now returns 409 and keeps the row instead of deleting the wrong one. ### How was this patch tested? `testDeleteWithObservedVersionOnlyRemovesThatIncarnation` in the five meta-service tests (H2, MySQL, PostgreSQL); `testDropTableLeavesRegistrationRecreatedDuringTheDropAlone`, `testDropTableDeletesTheObservedRegistration`, `testAlterTableDoesNotUpdateARegistrationWithAnotherId` in `TestTableOperationDispatcher`; all `*OperationDispatcher` and `*HookDispatcher` suites pass. -- 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]
