JingsongLi commented on PR #10272: URL: https://github.com/apache/paimon/pull/10272#issuecomment-5936382752
[P2] Preserve retries for transient SQLite write contention `AbstractDistributedLockDialect.java:66–69` now rethrows `SQLITE_BUSY`/`SQLITE_LOCKED`, although these are recoverable database write contention rather than a broken lock table. SQLite is a supported JDBC lock dialect, and its driver defaults to a 3000 ms busy timeout while the catalog lock acquire timeout defaults to 8 minutes. Another writer can acquire the database write lock between the cleanup DELETE and the lock INSERT; a transaction lasting slightly longer than the driver timeout now aborts the catalog operation immediately instead of retrying within the catalog timeout. I reproduced this through the actual `JdbcCatalogLock.runWithLock` and two connections to a local SQLite file: after the cleanup DELETE succeeds, the other connection runs `BEGIN IMMEDIATE` and commits 3.5 seconds later. At this PR's HEAD, the operation throws `[SQLITE_BUSY] The database file is locked` after 3214 ms and never runs the protected callback. With only `AbstractDistributedLockDialect` replaced by its merge-base implementation, the same program retries and runs the callback successfully after 3562 ms. This deliberately places contention after cleanup, since failure of the cleanup DELETE itself already propagated before this PR. Please preserve retry behavior for dialect-specific transient lock errors (at least SQLite BUSY/LOCKED), while continuing to surface non-retryable configuration/connection errors. A real two-connection regression test should cover this distinction. The normal JDK 8 reactor run of `JdbcCatalogTest` passed all 78 tests, but the current tests do not cover this contention window. -- 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]
