LuciferYang opened a new issue, #10953: URL: https://github.com/apache/paimon/issues/10953
### Search before asking - [X] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Paimon version master (bf6c81cbc8) ### Compute Engine JavaAPI ### Minimal reproduce step A filesystem-managed table on an object store whose rename is not atomic, committed by several writers with a lease-based catalog lock (for example JDBC or Hive with `lock.enabled = true`), as the [concurrency control docs](https://paimon.apache.org/docs/master/concepts/concurrency-control/) recommend. A commit's request that checks whether the new snapshot file already exists takes longer than the lease. `RenamingSnapshotCommitTest#testCommitRechecksLeaseAfterCheckingSnapshot` in the linked PR reproduces it with a lock whose lease expires inside that existence check. ### What doesn't meet your expectations? The commit still publishes the snapshot after its lease has expired, when another writer may already hold the lock. `SnapshotCommit.commit` checks the lease (`Lock.ensureValid()`) before it calls `RenamingSnapshotCommit.commitImpl`. `commitImpl` then calls `fileIO.exists(newSnapshotPath)` and, if the file is absent, `tryToWriteAtomic`, with no check in between. The existence check is a remote request on object stores, so it can outlast the lease. ### Anything else? #10845 found the same gap in `fast_forward` (a lease check followed by an existence check and then the write). ### Are you willing to submit a PR? - [X] I'm willing to submit a PR! -- 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]
