Optimistic Locking
Optimistic locking postpones locking the occurrence until the modified data is actually stored. This causes the lock to be applied at the last possible moment, which can result in considerable performance improvements in multiuser environments, especially for On-line Transaction Processing (OLTP).
Optimistic locking assumes that two users will not modify the same occurrence at the same time. If this does happen, the first user to store the modified occurrence becomes the first person to apply the lock and so does this successfully. Any other user who tries to store data which was retrieved before that lock loses the transaction. This is because their retrieved data no longer matches the data on disk.
In this way, the integrity of the database remains protected. The penalty is that users sometimes have to run their transactions again. If this is likely to happen frequently, optimistic locking is not a good idea.
ProcScript
If optimistic locking has been defined for an entity, or the DBMS applies this kind of locking, Uniface ignores the lock instruction when it is issued. The lock instruction is usually coded in the Lock trigger, which the structure editor activates as soon as an occurrence is modified.
Instead of this lock, Uniface locks an occurrence automatically when the write or delete instructions are issued. Uniface also checks at that time whether the occurrence in the component is still the same as the one in the database. If it is not (that is, another user has modified or deleted it in the meantime), the user receives an error message and must start the transaction again.
Defining Optimistic Locking
To define optimistic locking for an entity, set
the Locking property of the modeled entity to Optimistic.
