Locking Strategy (Magic xpa 4.x)

This property defines when Magic xpa issues locks to prevent other users from accessing the record processed by the current task, and whether verification is performed for the information contained in the memory. Verification is performed according to the selected Identify Modified Row option, which determines how Magic xpa re-reads the record to update it.

The Locking Strategy property has the following values:

Immediate – Magic xpa locks the record immediately as it is fetched and displayed to the end user (at the Before Record Prefix level). No verification is required. The record is kept locked until it is released. This is the default used for Batch tasks and is recommended for Batch tasks, since the record loop is usually very short. This strategy increases data integrity, but reduces concurrency. In interactive tasks, in a multi-user environment, using the Immediate Locking strategy, may cause prolonged locks of records, as the period of time that a user may remain in the same program is unpredictable.

This value applies only to the Physical transaction mode.

On Modify – Magic xpa locks the record as soon as the user commits to updating the record. In Online and Rich Client tasks, this is when the first character is typed into an input column, or the first value is selected from a selection table. In Batch, as there is no user interaction, the lock is issued on the first Update operation executed in a Record Suffix or Record Prefix logic unit, or the first called task or program, which causes a lock.

If the record has been changed between the time it was first read and the time that it was locked, the engine will re-read the record and show its updated values.

The On Modify strategy applies to Deferred and Physical transaction modes.

This option is recommended for Online tasks in which we want to lock the records only if the user updates the record.

For the On Modify locking strategy, modification verification is required. Magic xpa will issue a lock in the following cases:

• Modifying an input column.

• Calling a task or program in which the Lock property is set to Yes.

• The task executes a non-abortable Update operation.

• The import form operation is executed.

• Event programs will lock the data view of the event.

Before Update – Magic xpa locks the record only before the actual write to the database. This means that the record is not locked during the interaction stage (online) and not during the Record Suffix operations for Online and Batch tasks. If the data verification stage of the lock fails (the record was updated by another user since the last read), the update will not be carried out, and a message to that effect will be issued to the user ("Record has been changed..."). As a result, there is the possibility in this mode of losing updated data. Subtasks called by the current task may have updated information to other tables, thus possibly causing inconsistency if the current record is not updated to the disk. Since the transaction duration is short, concurrency is increased, but at the expense of data integrity. It is recommended that you only use the Before Update locking strategy in cases where locking the underlying database would be problematic, and where the task structure ensures that there would be no loss of update data should the verification fail.

This locking strategy option applies only to the Physical transaction mode.

No Lock – The record is not locked. The No Lock option should be used with caution, because in this case Magic xpa may update records that have been accessed and updated by other workstations causing loss of data integrity. No Lock is the default setting for Online tasks.

Magic xpa will not issue locks to a database before sending the changes to the database. This option is not recommended for Physical transaction tasks that delete/update records. Using No Lock as the locking strategy raises two problems:

1. There is no check to see if the record was changed. The user may update the record according to old values.

2. Magic xpa will issue the relevant DML command without locking the record. DML commands have no “NOWAIT” parameter and if the record was locked by another user, Magic xpa will wait until the release of the lock on the record. Magic xpa does not have control of this and it may seem as if Magic xpa is not responding.