🔒 Locking Support on Informix in Uniface 10.4

This article explains how locking works with Informix in Uniface 10.4 and why the U_VERSION field can help you reduce locking conflicts. 😊

This post was created with the help of an AI assistant and is based on the Uniface 10.4 documentation.

🚦 Why locking matters

When many users work with the same data at the same time, you need a way to protect your data from conflicts and overwrites.

Locking tells the database: “This row is in use, please do not change it from other sessions right now.”

• Users may overwrite each other’s changes.
• You can lose data or store inconsistent data.
• Errors can be hard to reproduce because they appear only under load.

🧱 Prerequisite: Transaction logging in Informix

Informix cannot lock records in the way Uniface needs unless transaction logging is enabled on the database.

If transaction logging is not enabled, Uniface recommends using the U_VERSION mechanism instead to reduce locking conflicts.

When transaction logging is enabled:

• Informix can support the locking behavior that Uniface expects.
• The Uniface Informix connector ensures that your operations run inside a transaction.

Simple rule:

Before using full locking support with Uniface and Informix, make sure the Informix database has transaction logging turned on.

🧩 Locking types in Uniface

Uniface supports the following locking strategies when working with Informix: optimistic, cautious, and paranoid.

• Optimistic locking Assume that other users usually do not change the same data at the same time. Conflicts are checked when you store the data.
• Cautious locking (default) Lock rows earlier in the process to reduce conflicts, but this can use more locks.
• Paranoid locking Lock very aggressively. This further reduces the risk of conflicts, but can block other users more often and increase lock usage.

The default locking type is cautious, and the locking granularity is row-level locking.

Row-level locking means Informix locks individual rows instead of entire pages or tables.

This is helpful because:

• Only the rows you actually change are locked.
• Other users can still work on different rows in the same table.

⚠️ Maximum number of locks in Informix

Informix has a maximum number of locks that can be held at the same time.

The exact limit depends on the platform and on Informix configuration parameters such as LOCKS.

Things to keep in mind:

• If your Uniface application holds many locks (for example with paranoid locking or long-running transactions), you can reach this limit.
• If the lock table is full, further operations that need new locks can fail with lock-related errors.

Work with your Informix administrator to:

• Configure the LOCKS parameter with a reasonable value.
• Monitor lock usage under real workload.

🟢 What is U_VERSION?

Uniface supports a version mechanism to improve locking behavior and performance.

This mechanism uses a special field called U_VERSION.

Key facts about U_VERSION:

• It is a one-byte field that you define in the entity (table).
• The Uniface runtime recognizes this field specially.
• When a row is changed, Uniface updates the U_VERSION value.

U_VERSION is used to detect whether a row was modified by another user after it was retrieved.

Because of this, Uniface can reduce the need to hold locks for a long time and can avoid some re-read operations under cautious or optimistic locking.

The documentation recommends using U_VERSION, because it significantly reduces the chance of locking conflicts in multi-user environments.

💡 Simple example: Using U_VERSION to avoid conflicts

Imagine two users, Alice and Bob, editing the same customer record at the same time.

Without U_VERSION:

1. Alice reads the customer row.
2. Bob reads the same row.
3. Bob changes and stores the row.
4. Alice also stores her changes. The system may overwrite Bob’s update or produce a locking conflict, depending on the locking strategy and timing.

With U_VERSION:

1. Alice reads the row, including U_VERSION, for example value 5.
2. Bob reads the same row with U_VERSION 5.
3. Bob changes and stores the row. Uniface increments U_VERSION to 6.
4. Alice tries to store her changes. Uniface sees that the current U_VERSION in the database is 6, not 5.
5. Uniface detects a conflict and can prevent silent overwrites by returning an error or status code so the application can reload the data.

This pattern helps you:

• Avoid lost updates.
• Detect concurrent changes safely.
• Keep transactions and locks shorter, because the main check happens when storing.

🛠️ Practical tips for Uniface + Informix locking

Here are some practical tips when you work with Uniface 10.4, Informix, and locking:

• Enable transaction logging Turn on transaction logging for your Informix database so Uniface can use locking as designed.
• Use U_VERSION on frequently updated tables Add a U_VERSION field to entities with many updates to reduce locking conflicts and improve performance.
• Keep transactions short Avoid long-running transactions that keep many locks open. Shorter transactions mean fewer conflicts and less pressure on the lock table.
• Monitor lock usage Check Informix lock statistics with your DBA and adjust the LOCKS configuration parameter if needed.
• Choose a suitable locking strategy Start with the default cautious locking. Switch to optimistic or paranoid locking only when you understand the impact on conflicts and lock usage.

✅ Summary

Informix needs transaction logging enabled to support Uniface locking in the required way.

Uniface supports optimistic, cautious (default), and paranoid locking with row-level granularity.

Informix has a maximum number of locks, so you must design your transactions and locking strategy carefully.

Using the U_VERSION field is recommended, because it reduces locking conflicts and helps Uniface detect concurrent updates.