Informix Error -134

Reasons / Common Causes

-134 is different from -107's single-row conflict: this isn't about a specific row being locked by someone else, it's about the engine's entire lock table running out of capacity for any new lock, row or index page. The official text is direct that the number of locks an operation needs depends primarily on how many rows a single transaction modifies.

1. A single large transaction modifying many rows, each requiring its own lock, consuming a large share (or all) of the configured lock capacity by itself.
2. Many concurrent sessions each holding a moderate number of locks, collectively exceeding capacity even though no single transaction is individually unusual.
3. Row-level locking used for what's effectively a bulk operation — a large UPDATE, DELETE, or INSERT affecting many rows, consuming one lock per row when table-level locking would have used a single lock for the whole operation.
4. Long-running transactions holding locks far longer than necessary, increasing peak concurrent lock usage for the duration they're open, not just at the moment of the largest individual operation.
5. The configured lock limit set too low for actual workload — undersized relative to real concurrency and typical per-transaction row-modification counts.
6. Index page locking adding to the count. The official text notes this covers index pages as well as rows — heavy index churn or a poorly selected index can add lock pressure beyond what row-level locking assumptions alone would suggest.
7. A batch/ETL job processing everything in one giant transaction rather than committing in smaller batches, intentionally or as an oversight.

Solutions / Resolution

1. Reduce transaction scope — do less per transaction, committing in smaller batches. This directly reduces peak lock consumption for that transaction and is usually the most effective fix for a single oversized operation.
2. Use table-level locking for bulk maintenance operations where row-level isolation isn't actually needed:

   LOCK TABLE inventory IN EXCLUSIVE MODE;
   -- perform the bulk update as one operation under a single table lock
   UNLOCK TABLE inventory;
   

   This trades row-level concurrency for dramatically lower lock consumption — appropriate for maintenance windows where exclusive access is acceptable anyway.
3. Increase the configured number of available locks. Per the official guidance, this limit lives in one of three places depending on the implementation: the OS kernel, the shared-memory segment, or the database server's own configuration (LOCKS parameter) — identify which one applies and work with the administrator to raise it.
4. Shorten long-running transactions so they don't hold locks longer than necessary, reducing peak concurrent usage system-wide, not just for any one transaction.
5. Restructure batch/ETL jobs into smaller committed units if a single giant transaction is the root cause, rather than one operation attempting to modify everything at once.
6. Monitor lock usage trends proactively to catch approaching the ceiling before it causes a hard failure, rather than discovering the limit reactively.

Examples

The oversized single transaction

BEGIN WORK;
UPDATE orders SET archived = 1 WHERE order_date < TODAY - 365;
-- affects 2 million rows in one transaction — -134 if this exceeds
-- the configured lock capacity
COMMIT WORK;

Restructured into smaller committed batches:

-- Repeat in a loop, committing between iterations
BEGIN WORK;
UPDATE orders SET archived = 1
WHERE order_date < TODAY - 365 AND archived = 0
  AND order_id IN (SELECT FIRST 10000 order_id FROM orders
                    WHERE order_date < TODAY - 365 AND archived = 0);
COMMIT WORK;

Table-level locking for a maintenance operation

LOCK TABLE archive_staging IN EXCLUSIVE MODE;
DELETE FROM archive_staging WHERE processed = 1;
UNLOCK TABLE archive_staging;

One lock for the whole operation instead of one per deleted row — appropriate when this table isn't being concurrently accessed by anything that needs row-level granularity during the maintenance window.

Collective exhaustion from concurrent sessions

Several sessions each running moderately sized updates (a few thousand rows each) at the same time can collectively exhaust the lock table even though any single one of them would have succeeded in isolation — the fix here is either raising the configured limit or staggering the concurrent load, not shrinking any individual transaction further.

Diagnostic Checks

1. Check lock-table usage directly:

   onstat -p
   

   Look for a usage count near the configured limit, or evidence of overflow.
2. Review the failing transaction's scope — how many rows did it actually modify, and does that account for a large share of the configured lock capacity by itself?
3. Check the LOCKS configuration parameter and compare it against actual observed peak usage from onstat -p.
4. Check for other concurrent sessions' lock usage at the time of failure, to distinguish a single oversized transaction from collective pressure across several moderate ones.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -107 — "ISAM error: record is locked." The single-row-conflict sibling — -107 means a specific row is already locked by someone else; -134 means the lock table itself has no capacity left for any new lock, row or index page.

Before raising the configured lock limit, check whether a single oversized transaction or an unnecessarily row-level-locked bulk operation is the actual cause — reducing transaction scope or switching to table-level locking for a bulk operation often resolves this without needing any configuration change at all.