Informix Error -154

Reasons / Common Causes

-154 covers two related but distinct situations, both timeout-driven rather than a deterministic lock-conflict detection:

1. A suspected distributed deadlock, detected by timeout. This is the mechanism -143 describes for Informix STAR environments: a request waiting on a lock held by a remote system, which is itself waiting on a resource owned by the local system, can't be detected through an instantaneous cross-system wait-for graph. Instead, once the wait exceeds the configured deadlock timeout interval, the local server assumes a distributed deadlock exists and aborts the request — this error is that assumption being reported.
2. An explicit wait-time limit expiring, independent of any actual deadlock. If SET LOCK MODE TO WAIT 3 is in effect and a lock request sits queued for more than 3 seconds, the operation terminates with this same error — whether or not a real deadlock exists. Heavy, ordinary (non-circular) contention that simply takes longer than the configured wait duration produces the identical error code as a genuine suspected distributed deadlock.

Because both paths report the same code, distinguishing them matters for deciding what to do next:

3. A deadlock timeout interval configured too short for actual normal cross-system latency and contention patterns produces false-positive "suspected deadlock" aborts on requests that were merely slow, not genuinely deadlocked.
4. An explicit SET LOCK MODE TO WAIT <n> value set too aggressively low for the environment's real contention levels produces the same error routinely under heavy but entirely ordinary load, with no deadlock involved at all.
5. Frequent occurrence is itself informative — it points at either a genuinely recurring distributed deadlock pattern (a design issue, per -143's guidance) or a timeout configured too tightly for normal operation, and the two call for different responses.

Solutions / Resolution

1. Roll back the current transaction and retry after a delay, per the official guidance — the same shape as -107's and -143's remedy, appropriate for both the distributed-deadlock and the plain-timeout case.
2. If this occurs frequently, have the database administrator adjust the deadlock timeout interval — the same trade-off discussed for -143: too short risks false positives against merely slow transactions; too long delays real deadlock detection.
3. For the explicit SET LOCK MODE TO WAIT <n> case, review whether the configured wait duration is appropriate for actual typical contention and latency in the environment — a value that's routinely exceeded under ordinary load is simply too short for this workload.
4. If genuine distributed deadlocks are the recurring driver (not just timeout tuning), apply the same structural fix as -143: enforce consistent resource-acquisition ordering across systems to eliminate the possibility rather than relying on timeout-based detection to keep catching it.
5. Build retry-with-backoff into applications for this error, same as for -107/-143/-144 — occasional occurrences, true or false-positive, are a normal part of concurrent and distributed operation.

Examples

Distributed deadlock, timeout-detected

-- Host A: session waiting on a resource held by Host B
-- Host B: session waiting on a resource held by Host A
-- Neither side's wait-for graph alone reveals the cycle;
-- Host A's wait exceeds the configured deadlock timeout interval
-- -154: Host A assumes a distributed deadlock and aborts

Plain timeout under heavy, non-deadlocked contention

SET LOCK MODE TO WAIT 3;
UPDATE hot_counter SET value = value + 1 WHERE id = 1;
-- -154: the row is under heavy contention from many concurrent
-- sessions; this particular request simply waited longer than
-- 3 seconds, with no actual deadlock involved

Raising the wait duration, or redesigning around the hot-row contention itself (see -134's guidance on high-contention rows), addresses this differently than a genuine distributed deadlock would.

Diagnostic Checks

1. Determine whether the failure occurred in a distributed/STAR context or from a local SET LOCK MODE TO WAIT <n> timeout — the session/environment context distinguishes which of the two situations actually applies.
2. Review the frequency of this error to decide between timeout tuning and investigating a genuinely recurring deadlock design issue.
3. Check the configured deadlock timeout interval and the SET LOCK MODE TO WAIT value in use.
4. Review for long-running or heavily blocking transactions if a false-positive-via-heavy- contention explanation (rather than an actual deadlock) is suspected.

Related Errors / Related Topics

• -143 — "ISAM error: deadlock detected." The deterministic sibling — -154 is what the probabilistic, timeout-based version of the same underlying concern looks like in a distributed environment, or what a plain explicit wait-mode timeout looks like locally.
• -107 — "ISAM error: record is locked." The base lock-conflict condition this entire family builds on.

Distinguish a genuine (suspected) distributed deadlock from an ordinary wait-mode timeout before deciding what to tune — they call for different fixes even though they report the same code.