JDBC catalog lock swallows non-contention SQL errors as lock contention and busy-spins

[LuciferYang]

Search before asking

• I searched in the issues and found no similar issues.

Paimon version

master (1.5-SNAPSHOT)

Compute Engine

Any engine using the JDBC catalog with catalog lock enabled.

Minimal reproduce step

1. Configure a JDBC catalog with the catalog lock enabled.
2. Put the lock-acquire INSERT into a non-contention failure, for example drop or rename the distributed_locks table, or let the pooled connection go dead.
3. Perform an operation that acquires the lock (for example a commit).

What doesn't meet your expectations?

AbstractDistributedLockDialect.lockAcquire catches every SQLException and returns false, which the caller reads as "lock is held by someone else". So a non-contention error (missing lock table, dead connection, access denied) is treated as contention: JdbcCatalogLock.lock() busy-spins for the whole lock-acquire timeout re-issuing the same failing statement, then throws a generic Acquire lock failed with time: ... that hides the real cause. A non-retryable failure should fail fast and surface its root cause.

Anything else?

Real contention does surface as a primary-key constraint violation on the lock row, so returning false and retrying is correct for that case and should stay.

Are you willing to submit a PR?

• I'm willing to submit a PR!