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.