Application lock wait timeout (GET_LOCK)
ER_APPLICATION_LOCK_WAIT_TIMEOUT (4046) is returned when GET_LOCK() exceeds the specified timeout without acquiring the named advisory lock. This is MariaDB's distinct error code for application-level lock timeouts, separate from InnoDB row lock timeouts.
-- Session 1 holds the lock:
SELECT GET_LOCK('my_job', 0); -- returns 1
-- Session 2 times out waiting:
SELECT GET_LOCK('my_job', 5); -- waits 5s then returns 0 (timeout)expected output
-- GET_LOCK returns 0 on timeout; the error is raised in strict contexts
Fix
Check the return value of GET_LOCK and handle contention
WHEN Using advisory locks for distributed coordination.
SET @got = GET_LOCK('my_job', 10);
IF @got = 1 THEN
-- do work
DO RELEASE_LOCK('my_job');
ELSE
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Could not acquire lock — retry later';
END IF;Why this works
GET_LOCK returns 1 on success, 0 on timeout, and NULL on error. Checking the return value allows graceful fallback instead of an unhandled exception.
✕ Use GET_LOCK with a very long timeout as a substitute for proper queue management
Long-held advisory locks block other sessions; use a proper job queue (e.g. Redis, SQS) for distributed locking at scale.
Error 4046 was added in MariaDB 10.5 to distinguish application lock timeouts from InnoDB lock timeouts (1205).
MariaDB — GET_LOCK()
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev