Change Verify

In a multi-user system, it is always possible that two users may attempt to update the same record at the same time. In the DP4 system, this type of contention is handled by a change verify process. This procedure allows each user to read the same record from the database. The first user to request an update will be able to do so, and the second will have their commit rejected. If a commit fails, the application may re-read the record and request the update again, after making any necessary adjustments. This type of contention control is also known as optimistic contention control. It is very efficient in systems where there is little contention, as it avoids the overhead of record locking.

In the figure on the right, user A and B read the material record at the same time. User A completes the transaction first and changes the value of the 'Quantity In Stock' field to 401. The record is updated on the database. User B still has 421 as the 'Quantity In Stock' value, and so if user B were allowed to update the database, the new value would not reflect the updates made by user A.

In DP4, if user B attempts to change the record, the attempt to commit the transaction returns an update failure message to the application, to indicate that the record has been updated since user B read it from the database. Normally, user B will re-read the record and modify the changed version of the record. As a developer, you have the choice of whether to make this process automatic, or to leave it to the user.