Managing concurrency

The default template manages concurrent access.

Concurrent access occurs when two or more users work on the same data, such as when more than two users are working with the same application or with different applications using common data.
Note:

With mobile apps, only one user accessing the app at any given time; data cannot be altered by another user. Concurrent access management is disabled for generated mobile apps.

The default template checks for concurrent access and notifies the user that the data being updated has been changed by another user (either deleted or updated). The concurrent access only applies to data of the current row. The check of the concurrent access is systematically done when the user:
  • starts to modify the current row
  • saves updates to the current row
  • deletes the current row
If the user's data was not updated by another user the application follows its normal course, such as insert, update or delete of the current row.

If the user's data was updated by another user, a warning is raised and the user is asked to refresh the data. If the user rejects the request to refresh the data, the application stays in its current state and the application's process does not continue. If the user accepts the request to refresh the data, the current row is refreshed.

If the user's data was deleted by another user a warning is raised and the user is asked to refresh the data. If the user rejects the request to refresh the data, the application stays in its current state and the application's process does not continue. If the user accepts the request to refresh the data, the current row is deleted from the current data set.

Concurrent access management uses the optimistic locking strategy. The data that the user wants to update or delete is compared to what is stored in the database ensuring no change has occurred. A check is done when starting to modify the current row in the application to detect data modification at the earliest. See the topic Optimistic Locking in the Genero Business Development Language User Guide for more information.
Note:

In the database layer, the default template uses physical row locking for update and delete operations. This ensures data cannot be changed during the database transaction. Physical row locking can only be done with databases that handle locks.