Concurrency Control - Optimistic Locking

Using optimistic locking for concurrency control means that more than one user can access a record at a time, but only one of those users can commit changes to that record. Once one user has modified the record, another user cannot modify it without first re-reading the latest version of the record. Thus it is optimistic in the sense that one user does not expect another to attempt to modify the same record at the same time.

The record being edited is locked for update only while the changes are being committed. This has the advantage of minimizing the time for which a lock is in place.

The disadvantage of optimistic locking is that when a user begins to edit a record, they cannot be sure that the update will succeed. An update that relies on optimistic locking will fail if another user has updated a record while the first user is still editing it.

Optimistic locking is implemented by adding an extra field to the database table. The extra field contains the version number for the record and is automatically incremented each time the record is modified. The generated DAL code checks this version number while the record is being updated, and if the version number on the database table is not the same as the version number on the original record then the update operation is aborted and an exception is thrown.

Optimistic locking is permitted only on Entity classes.

The following operation stereotypes support optimistic locking:

• modify;
• nkmodify;
• nsmodify.

The following operation stereotypes are affected by optimistic locking:

• insert - The version number field is automatically included in the details parameter and is automatically initialized before being written to the database;
• nsinsert - If optimistic locking is enabled on an entity class, the version number field must be included in the details struct by the developer and will be automatically initialized before being written to the database.

Optimistic locking is only possible for operations which modify a single database record and whose details struct includes the generated Version Number field. This means that for non-standard operations, it is up to the developer to ensure that the non-standard key parameter always identifies a single unique record and that the Version Number field is included in the details struct. For nkmodify operations, optimistic locking is only possible if the database table contains exactly one record. This field must be called versionNo and its type should be VERSION_NO. The developer must ensure that the model contains a numeric domain definition named VERSION_NO.

In order to support optimistic locking on an operation you must do two things:

• Switch on theAllow Optimistic Locking option on the entity.

  This will cause the Version Number field to be automatically added to the entity.

• Switch on theOptimistic Locking option on the operation.

  This will cause the generator to generate code in the DAL for the operation which will check and update record version numbers accordingly.