Informix Error -289

Reasons / Common Causes

-289 is a straightforward table-level lock conflict, closely related to -113: another session already holds an exclusive lock on the table, and the current LOCK TABLE request can't be granted in the mode requested.

1. Another session already holds an exclusive lock on the table — a maintenance operation, a bulk update, or another explicit LOCK TABLE IN EXCLUSIVE MODE currently in progress.
2. The same general causes as -113 — a long-running exclusive transaction holding the table longer than expected.

Solutions / Resolution

1. Wait for the table to be unlocked, per the official guidance — this is normally transient.
2. Apply the same retry-with-backoff approach as -113/-233.
3. Coordinate scheduling of exclusive-lock-requiring operations to reduce contention, if this recurs regularly against the same table.

Examples

The ordinary transient conflict

-- Session A
LOCK TABLE inventory IN EXCLUSIVE MODE;
-- performing maintenance

-- Session B, at the same time
LOCK TABLE inventory IN EXCLUSIVE MODE;
-- -289: inventory is already exclusively locked by session A

Retrying session B's request once session A's maintenance completes succeeds without any code change.

Diagnostic Checks

1. Check current lock holders on the table:

   onstat -k
   

2. Review scheduling if this recurs regularly against the same table, to identify overlapping maintenance windows.

Related Errors / Related Topics

• -113 — "ISAM error: the file is locked." The closest sibling — same general table-level exclusivity conflict family.
• -233 — "Cannot read record that is locked by another user." Related through the same broader lock-conflict family, though for row-level reads rather than table-level locking.

Wait and retry — this is normally transient, resolving once the exclusive holder's operation completes.