🔒 Locking Support on Informix in Uniface 10.4

🚦 Why locking matters ## 🧱 Prerequisite: Transaction logging in Informix ## 🧩 Locking types in Uniface ## ⚠️ Maximum number of locks in Informix ## 🟢 What is U_VERSION? ## 💡 Simple example: Using U_VERSION to avoid conflicts ## 🛠️ Practical tips for Uniface + Informix locking ## ✅ Summary 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. 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.” 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: Simple rule: Before using full locking support with Uniface and Informix, make sure the Informix database has transaction logging turned on. Uniface supports the following locking strategies when working with Informix: optimistic, cautious, and paranoid. 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: 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: Work with your Informix administrator to: 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: 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. Imagine two users, Alice and Bob, editing the same customer record at the same time. This pattern helps you: Here are some practical tips when you work with Uniface 10.4, Informix, and locking: 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. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - 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. - Informix can support the locking behavior that Uniface expects. - The Uniface Informix connector ensures that your operations run inside a transaction. - 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. - Only the rows you actually change are locked. - Other users can still work on different rows in the same table. - 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. - Configure the LOCKS parameter with a reasonable value. - Monitor lock usage under real workload. - 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. - Alice reads the customer row. - Bob reads the same row. - Bob changes and stores the row. - Alice also stores her changes. The system may overwrite Bob’s update or produce a locking conflict, depending on the locking strategy and timing. - Alice reads the row, including U_VERSION, for example value 5. - Bob reads the same row with U_VERSION 5. - Bob changes and stores the row. Uniface increments U_VERSION to 6. - Alice tries to store her changes. Uniface sees that the current U_VERSION in the database is 6, not 5. - Uniface detects a conflict and can prevent silent overwrites by returning an error or status code so the application can reload the data. - Avoid lost updates. - Detect concurrent changes safely. - Keep transactions and locks shorter, because the main check happens when storing. - 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.