Informix Error -129: ISAM error: too many users.

Reasons / Common Causes

-129 means the shared-memory segment this ISAM implementation depends on was configured for a maximum number of concurrent "users," and that limit has been reached. The official text is specific about terminology worth internalizing before debugging this: "users" means concurrent application programs/sessions, not individual people. One person can easily hold several sessions open at once — the official text's own example is running the 4GL Programmer's Environment alongside a separate compiler session — and each counts separately toward the limit.

1. Connection pools sized larger than actually needed. Application-side connection pooling configured generously "to be safe" can open far more concurrent sessions than the workload genuinely requires, consuming capacity against a limit sized for real concurrent need.
2. Session leaks. Sessions not closed properly after use accumulate over time — the actual number of active, useful sessions might be modest, but a leak means the count the engine sees keeps climbing until it hits the configured maximum.
3. One person or one integration legitimately running multiple concurrent sessions. Several terminal sessions, a development tool plus a separate compiler process, or several batch jobs from the same workflow each count individually — this can be entirely legitimate and still be the reason the limit is reached.
4. Workload growth outpacing the original sizing. The shared-memory user limit was configured based on concurrency needs at some point in the past; more application instances, more batch jobs, or more integrations added since then can outgrow that original figure without anyone revisiting the configuration.
5. Stale sessions from crashed or improperly disconnected processes not being cleaned up promptly, continuing to count against the limit until the engine detects and reclaims them.
6. Multiple separate applications or services sharing one ISAM instance, collectively exceeding a limit that was sized around a single application's expected concurrency rather than the combined total.

Solutions / Resolution

1. Increase the configured maximum number of concurrent users for the shared-memory segment if actual legitimate need genuinely exceeds the current setting — this is an administrator task and typically requires a restart to take effect.
2. Review and right-size application connection pool configuration — reduce pool sizes to match actual need rather than provisioning well beyond it "to be safe."
3. Fix session leaks — audit code paths (especially error-handling paths) for sessions opened but never explicitly closed.
4. Audit for stale or orphaned sessions from crashed processes, and confirm the engine's own session-cleanup/timeout behavior is configured to reclaim them promptly.
5. When multiple applications or services share one ISAM instance, size the configured limit around their combined concurrency needs, not any single application's needs considered in isolation.
6. Monitor actual concurrent session counts over time to catch a growth trend before it hits the configured limit, rather than discovering the ceiling reactively when -129 first appears.

Examples

An oversized connection pool

# Application connection pool configured for 200 connections
# "to handle peak load," but actual observed peak concurrency is 40

The pool consuming capacity for 200 potential concurrent sessions, when the real workload only ever needs a fraction of that, leaves far less headroom for other applications or growth than the number "200" might suggest was intended.

The slow session leak

/* Error path forgets to close the session before returning */
fd = connect_to_database();
if (validate_input() < 0) {
    return -1;             /* leaked: session never disconnected */
}
/* ... normal path correctly disconnects ... */

Every call taking the validation-failure branch leaves one more session counted against the limit — the failure (-129) shows up only once enough leaked sessions accumulate, far from the code that actually causes it.

Legitimate multi-session use by one person

A developer runs the 4GL Programmer's Environment in one window and a separate compiler session in another, both connected concurrently — exactly the official text's own example of two sessions from one person, each counting individually toward the limit.

Diagnostic Checks

1. Check current session count against the configured maximum:

   onstat -u
   

2. Review application connection pool configuration for pool sizes that may be larger than actual observed peak concurrency justifies.
3. Check for long-lived or idle sessions that might indicate a leak rather than genuine active use.
4. Review the shared-memory user-limit configuration parameter directly, and compare it against actual historical peak concurrency.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -123 — "ISAM error: no shared memory." The closest sibling — both are shared-memory capacity/configuration conditions; -123 means the segment doesn't exist at all, while -129 means it exists but its configured user-count ceiling has been reached.

Before increasing the configured limit, rule out a connection-pool oversizing issue or a session leak first — raising the ceiling on either just delays the same problem rather than fixing it.