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.
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 BDL 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. Note that physical row locking can
only be done with databases that handle locks.