Record Locking

When Rekall retrieves data to be displayed in a form, it fetches all the records from the server database and keeps this information locally. It only updates its data if the user makes a change to the record, in which case Rekall will refetch the updated record from the server database. However, if the table or tables that are displayed in the form are being accessed and updated by another client (maybe another instance of Rekall or maybe some other client) then it is possible that Rekall's view of the data can become out of date.

This can be overcome using record locking. Note that, at the time of writing, this requires the server database to support transactions and the select ..... for update query syntax, and is only implemented in the pgsql; driver

Record locking is controlled by the Record locking property in the block properties dialog. Currently, there are two settings, None and Lock row on update. The former is the default; if selected then no record locking takes place.

Please consult the appropriate database driver appendix for notes relevant to record locking.

Lock Row on Update

With this setting, Rekall does not attempt to lock a record until the user attempts to make a change, for instance by editing a field control or changing a choice control. This means that the user can move back and forth through the records without the overhead of any server database interactions.

As soon as the user tries to make a change, Rekall starts a transaction, and refetches the record from the server database using a select ... for update query. This should lock the record on the server database so that it cannot be changed by any other client. If the select ... for update fails then Rekall assumes that the record is locked by some other client, in which case the user is warned and the data displayed in the form is left unchanged (and the transaction is cancelled).

If the select ... for update does succeed, then Rekall compares the record returned from the server database with its copy of the data (ie., what is being displayed in the form). If there is a difference, then the record has been changed by another client. In this case Rekall warns the user, updates its copy of the data (and updates the form), and cancels the transaction. This leaves the user free to decide whether to continue updating the data now displayed (in which case the whole cycle starts again) or to leave it alone.

If the select ... for update succeeds and the record has not changed, then Rekall allows the change made by the user, since it knows that it has an up-to-date copy of the record and that no other client can now make further changes to that record.

If the user saves the changes, then the updated record is written back to the server database and the transaction is committed. This unlocks the record so that other clients can update it. If the user cancels the changes then the transaction is rolled back, which leaves the record unchanged (and accessible by other clients).

Note that because this occurs inside a transaction, which is either committed or rolled back, any other server database updates (for instance made by a script) will similarly either be committed or rolled back.

If the user has caused a record to be locked, and then, before saving or cancelling the changes, moves to another form and tries to make a change that would also require another record to be locked, then this may be prevented. This is necessary since some (all? most?) server databases allow only one transaction at a time, and rekall; can only allow one locked update to proceed. The user is warned and cannot make any changes to the second record.