Cautious Locking
Cautious locking causes an occurrence to be locked at the time that a user makes the first modification to a database field in the entity, or when an erase statement is issued in a valid context. (For erase to be valid, the data must come from the database.) Cautious locking is the default Uniface locking method.
Note: In a web application, Cautious locking behaves in the same way as Optimistic locking. If multiple users modify the same data simultaneously, the modification made by one user is stored.
For this to work, ProcScript in the entity-level lock trigger must issue the lock statement. In other words, the structure editor activates the entity-level lock trigger whenever the user tries to change an occurrence which has been retrieved from the database.
If the lock fails, because the occurrence is already locked or has been changed by someone else in the meantime, the appropriate message is returned.
Cautious locking is the default Uniface locking method. Uniface activates the entity-level lock trigger whenever a user makes the first modification to an occurrence of that entity, unless you issue the read/lock statement in the read trigger of an entity, or define optimistic locking for that entity.
You cannot define cautious locking from within Uniface; if your DBMS uses optimistic locking by default, you cannot influence Uniface to change that situation, although you might be able to influence the DBMS. Check your DBMS documentation.
ProcScript
If a lock is issued and the occurrence is already locked, Uniface returns an error. This stops the user from modifying the occurrence until the occurrence is unlocked in the database.
If the occurrence is not locked, Uniface compares the occurrence which was retrieved with the occurrence from the database. If a difference is detected between the two, Uniface displays a message and sets $status to -10. If the occurrence in the component does not match the database occurrence, this means that another user probably retrieved, modified and stored the occurrence in the meantime. The reload statement retrieves the current occurrence back into the component, using the primary key as the retrieve profile.
DBMS Behavior
Databases vary in their locking behavior (optimistic locking might be the DBMS default, or different locking strategies are applied in different circumstances). For more information, see Database Integrity Support.
In most circumstances, cautious locking provides the maximum protection for the user because it prevents two users from updating the same occurrence at the same time.
Cautious locking can have negative effects on concurrency. However, if it is likely that a user modifies an important occurrence of an entity before another user has saved their modification to the same occurrence of the entity, you should define optimistic locking for that entity.
