yuqi1129 opened a new issue, #13206: URL: https://github.com/apache/gravitino/issues/13206
### What would you like to be improved? `TableOperationDispatcher.createTable`, `TopicOperationDispatcher.createTopic`, `ViewOperationDispatcher.createView` and `ModelOperationDispatcher.registerModel` take a **schema-level WRITE** tree lock and hold it across the connector call and the entity-store write. Every create in a schema is therefore serialized per JVM, and the preceding `loadSchema` READ lock queues behind the writer as well. A load test with 10 concurrent users creating Iceberg tables in one schema (JDBC backend, metadata on GCS) shows Gravitino REST create at P50 ~1 s / P95 ~2 s vs 270 ms for the Iceberg REST service on the same catalog. jstack sampling: 270 of 300 create-table threads parked in `TreeLockNode.lock`. Same code, 10 users spread over 10 schemas: 3.7x throughput. The connector commit (remote metadata write) dominates the lock hold time, so the ceiling is roughly `1 / commit latency` creates per second per schema. Filesets (#8881) and functions already lock the entity node instead of the schema. ### How should we improve? Lock the entity's own node with WRITE (ancestors READ) in the four create paths, as `FilesetOperationDispatcher` / `FunctionOperationDispatcher` do. This preserves every existing exclusion — dropSchema/createSchema (catalog WRITE), rename/drop/import (schema WRITE), same-name create/load/alter (entity node) — and only lets `list` run alongside an in-progress create, the trade-off already accepted in #8880 and the end state after the planned tree-lock removal. Add lock-semantics tests per dispatcher. Local result with the change: same-schema create 34 -> 103 rps, P50 270 -> 89 ms. -- 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]
