[Proposal] Implement "NoWait" Mechanism for DataBase Distributed Locking

[Sumit6307]

Check Ahead

• I have searched the issues of this repository and believe that this is not a duplicate.

• I am willing to try to fix this bug myself.

Ⅰ. Issue Description

The current DataBaseDistributedLocker implementation in server/src/main/java/org/apache/seata/server/storage/db/lock/DataBaseDistributedLocker.java relies on SELECT ... FOR UPDATE which can block threads until the database lock wait timeout is reached.

There is an explicit TODO in the code at line 150 acknowledging this limitation:
// ignore "Lock wait timeout exceeded; try restarting transaction"
// TODO: need nowait adaptation

In high-concurrency scenarios, this blocking behavior can lead to thread pool exhaustion in the Transaction Coordinator (TC) if database locks are contended but not released quickly. I propose to implement a "NoWait" or "Fast Fail" mechanism for the database distributed locker to improve system resilience.

Ⅱ. Describe what happened

When acquiring a distributed lock using DataBaseDistributedLocker , the system executes a blocking SQL query (SELECT ... FOR UPDATE). If the lock is held by another transaction, the current thread blocks and waits until the database lock timeout occurs (which can be several seconds). This consumes thread resources in the TC and delays the failure response to the client.

Ⅲ. Describe what you expected to happen

The DataBaseDistributedLocker should support a nowait adaptation as suggested in the code comments. When
acquireLock is called, it should attempt to acquire the lock using non-blocking SQL syntax (e.g., NOWAIT, SKIP LOCKED, or valid dialect equivalents). If the lock is unavailable, it should fail immediately ("Fast Fail") instead of blocking the thread, allowing the TC to handle the contention more efficiently (e.g., by retrying later or returning a failure status instantly).

Ⅳ. How to reproduce it (as minimally and precisely as possible)

1. Configure Seata Server to use db as the lock storage mode.
2. Start two global transactions that contend for the same resource lock (same xid or resource key).
3. Have the first transaction hold the global lock for a duration longer than the database lock timeout.
4. Have the second transaction attempt to acquire the same lock.
5. Observe that the second transaction's thread is blocked in DataBaseDistributedLocker.acquireLock until the DB timeout triggers.

Minimal yet complete reproducer code (or URL to code): Not applicable (Architectural enhancement proposal).

Ⅴ. Anything else we need to know?

My implementation plan includes:

1. Refactoring DistributedLockSqlFactory to support dialect-specific NOWAIT syntax (Oracle, PostgreSQL, MySQL 8.0+, etc.).
2. Updating DataBaseDistributedLocker to use these non-blocking queries.
3. Handling specific SQLExceptions to distinguish "Resource Busy" from other errors.

Ⅵ. Environment

JDK version: 8/11/17+
Seata client/server version: 2.x
Database version: MySQL 8.0+ / PostgreSQL / Oracle
OS: Windows / Linux / MacOS

[funky-eyes]

DataBaseDistributedLocker is limited to task coordination within the TC cluster to prevent multiple TC nodes from executing the same task simultaneously.
If a node cannot acquire the distributed lock, it simply exits the attempt on the assumption that another node is already handling the task; additionally, each task is executed by a single-threaded thread pool, so there is no risk of exhausting or blocking a thread pool.
Optimization proposals for increasing asynchronous task throughput are being discussed in issue #7993.
The global locks used by the AT mode are implemented in subclasses of the Locker class at https://github.com/apache/incubator-seata/blob/2.x/core/src/main/java/org/apache/seata/core/lock/Locker.java

[Sumit6307]

DataBaseDistributedLocker is limited to task coordination within the TC cluster to prevent multiple TC nodes from executing the same task simultaneously. If a node cannot acquire the distributed lock, it simply exits the attempt on the assumption that another node is already handling the task; additionally, each task is executed by a single-threaded thread pool, so there is no risk of exhausting or blocking a thread pool. Optimization proposals for increasing asynchronous task throughput are being discussed in issue #7993. The global locks used by the AT mode are implemented in subclasses of the Locker class at https://github.com/apache/incubator-seata/blob/2.x/core/src/main/java/org/apache/seata/core/lock/Locker.java

@funky-eyes
Thanks for the clarification regarding the scope of DataBaseDistributedLocker. I understand it is used for task coordination within the TC cluster and runs in a single-threaded pool, rather than for AT mode global locks.

However, I believe the "NoWait" mechanism is still a valuable optimization for this specific component:

1. Fail Fast: currently, if a lock is contended, the thread blocks until the database timeout (which can be seconds). NOWAIT would allow the attempt to fail immediately, freeing up the thread instantly rather than blocking it.

2)Existing TODO: There is an explicit // TODO: need nowait adaptation in DataBaseDistributedLocker.java (line 150), suggesting this was a planned improvement by the original authors.

Would you be open to a PR implementing this NOWAIT adaptation for DataBaseDistributedLocker to resolve that TODO and improve coordination efficiency?

[Sumit6307]

Hi @funky-eyes

Just following up on my previous message in case it got missed.
I’d love to get your thoughts on whether a PR implementing the existing NOWAIT TODO in DataBaseDistributedLocker (scoped only to TC task coordination, not AT global locks, and ideally behind a config flag) would be acceptable.