This is an automated email from the ASF dual-hosted git repository.
JingsongLi pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/paimon.git
The following commit(s) were added to refs/heads/master by this push:
new 7f7e874619 [doc] Remove useless doc in concurrency control
7f7e874619 is described below
commit 7f7e874619c5f858f895016ec72d362fb5985ab5
Author: JingsongLi <[email protected]>
AuthorDate: Thu Oct 15 16:34:35 2026 +0800
[doc] Remove useless doc in concurrency control
---
docs/docs/concepts/concurrency-control.md | 80 -------------------------------
1 file changed, 80 deletions(-)
diff --git a/docs/docs/concepts/concurrency-control.md
b/docs/docs/concepts/concurrency-control.md
index c6fb698436..cdc1f85d4a 100644
--- a/docs/docs/concepts/concurrency-control.md
+++ b/docs/docs/concepts/concurrency-control.md
@@ -72,86 +72,6 @@ The commit mechanism depends on the catalog and storage:
All writers of the same table must use a compatible commit mechanism and
shared locking
configuration. See [Catalog](./catalog) when choosing the metadata backend.
-## Commit Locks
-
-Configured catalog locks protect every snapshot publication attempt, including
the first attempt.
-The writer acquires the lock before reading the latest snapshot, validating
changes and preparing
-manifests. It checks that the lock is still valid immediately before
publishing. Each snapshot has
-its own scope: APPEND and COMPACT snapshots produced by the same commit
acquire separate locks.
-Post-commit callbacks run after the scope ends. Metadata-only manifest
replacement validates the
-caller's prepared layout against the current head while holding the lock.
-
-`Catalog.createLock` supplies a table-bound `Lock` with one `runWithLock`
contract. `CatalogLockFactory`
-binds the table, UUID and writer identity when creating a `Lock`.
-`SnapshotCommit` owns this lock together with its publisher resources. Its
`commit` method always
-uses the bound lock, including direct publication. Writers use
`SnapshotCommit.runWithLock` to
-cover head reads and preparation; publication reuses that scope and
revalidates the lease.
-Each catalog interprets its own lock configuration. Hive and JDBC define the
catalog options
-`lock.enabled`, `lock.type`, `lock-check-max-sleep` and `lock-acquire-timeout`
in their own options
-classes. For these catalogs, locking is enabled on object stores and disabled
on other filesystems
-unless explicitly set. The filesystem catalog does not interpret these
options. Catalogs without
-a locking policy use a no-op lock.
-Hive locks send heartbeats and validate ownership before publication. The
client's
-`hive.txn.timeout` must match the metastore timeout. JDBC locks renew their
-leases and use an internal owner ID for renewal and release. Existing JDBC
lock tables receive a
-nullable `lock_owner` column when the catalog initializes; this requires
permission to alter that
-table. Older clients can still read the table, but all writers should upgrade
before relying on
-owner-checked release after lease expiry. Each active Hive or JDBC scope owns
a renewal worker
-which is stopped when the scope ends, so blocked renewals do not occupy other
scopes' scheduling
-threads. Filesystem locks still depend on the storage's atomic publication
behavior; they do not
-provide a storage fencing token.
-
-## REST Catalog Commit Leases
-
-Catalog-managed Paimon tables in the REST catalog expose table-bound commit
leases through
-`Catalog.createLock` and the unified
-`Lock.acquire` / `Lock.runWithLock` contract. Set the persisted table property
-`rest.commit.lock-enabled = true` to enable server-side lease enforcement.
Independently, set
-`rest.commit.acquire-lock = true` in a writer's dynamic options to acquire a
lease for each
-publication attempt. Both options default to `false`. Enabling the table
capability alone does
-not make clients acquire leases. Requesting acquisition without the table
capability fails.
-External tables keep filesystem publication.
-Callers supply their exact `commitUser` and table UUID.
-Leases require the target branch's catalog-resolved UUID. Reload a view
switched to another branch
-from the catalog before using leases.
-Lock contention waits until `commit.timeout` when configured, independently of
publication retries.
-Scopes share a timer and a cached worker pool. The timer dispatches RPCs to
workers so a blocked
-renewal cannot block other scopes' scheduling. Each scope permits only one
in-flight renewal and
-cancels its own scheduled and in-flight renewal tasks when it ends, without
stopping the shared
-executors. Timer and worker threads exit after one minute of inactivity and
restart when needed.
-The timer stays alive while renewal tasks remain scheduled. The client
validates the lease's
-monotonic deadline before publishing. A failed operation stops renewal and its
lease expires
-automatically. The server keeps the lease duration fixed for each scope;
duration changes take effect
-on the next acquisition.
-
-The server must validate the current table incarnation, branch, authenticated
caller and exact
-owner, and atomically publish the snapshot and clear the lease. All snapshot
writers must honor
-active leases, including writers that do not request one. Each successful
snapshot publication
-ends its lease; a later publication must acquire another scope. Snapshot
comparison and file
-conflict validation remain necessary.
-
-For a table with lease enforcement disabled, the server can skip lease storage
access entirely.
-For a table with enforcement enabled, even writers with
`rest.commit.acquire-lock = false` must
-respect another writer's active lease. The server uses its own persisted table
property for this
-decision, rather than client options. Capability changes must be serialized
with publication and
-lease acquisition; disabling enforcement must not bypass an active lease.
-
-Automatic conflict rollback supplies the runtime branch and the expected
head's `fromSnapshot`.
-A known table or branch UUID is supplied as `tableId`; it is omitted only when
the target identity
-is unknown. Rollback does not carry writer identity or a snapshot UUID and can
execute independently
-of commit leases, including for legacy snapshots without a UUID.
-
-The server must validate the table incarnation and expected snapshot ID
atomically with rollback,
-before changing partitions or deleting files. For automatic conflict rollback,
it should also check
-that the current head is still a `COMPACT` snapshot and the target is its
predecessor, since snapshot
-IDs can be reused after rollback. A concurrent writer's publication remains
protected by its expected
-base snapshot UUID. Manual rollback can omit `fromSnapshot`.
-
-This is a commit admission lease, not a generation or fencing token. Requests
with the same
-commit user and authenticated caller share ownership. Use a unique commit user
per logical writer
-and preserve it during recovery. A server without the lease protocol rejects
acquisition rather
-than silently proceeding without protection.
-
## Files conflict
A writer validates file-level changes as well as the snapshot ID. For example,
if two compactors
