In order to provide data integrity when accessing feature and observation data, the Application Server may have to lock feature and/or observation temporarily against modification.
There are different lock types the Application Server might use simultaneously on the same feature, table 1 lists these lock types. The modification locks can be shared or exclusive. Shared modification locks can be applied to the same feature by several processes at the same time, shared locks will hinder all processes to modify the data protected by the lock. Exclusive locks can only be applied to a feature by one process, and only if the feature has no other locks applied. Other processes will not be able to apply a (shared or exclusive) lock on a feature as long as it is exclusively locked by one process. The process that applied the exclusive lock can still modify the feature's data or its observation data.
The Application Server allows to query the locking status of a specific feature. The locking status tells how many locks of which type are applied to a given feature. For performance reasons it is not possible to determine who (e.g. which execution of a calculated feature) holds a lock on a feature. To query the locking status of a specific feature the querying user must have read rights on that feature.
Lock type |
Resulting behaviour |
Feature data |
This lock will prevent modifications on the feature's base data, calculation data, type specific data and spatial data. The lock will also prevent approval for the feature, deletion of the feature, adding of feature comments. |
Observation modification |
This lock prevents the modification of existing observations. Note that this lock does not prevent from adding new observations. This lock will also prevent approval all observations, deletion of observations, adding comments to observations and deletion of the feature. |
Observation deletion |
This lock will prevent existing observations from being deleted and the feature from being deleted. |
Observation creation |
This lock will prevent the creation of new observations as well as the deletion of the feature. |
Table 1: Locks the Application Server can apply on a feature.
The Application Server does not implement any read locks. As an implication of this, it is possible to have dirty reads. E.g. it is possible to read observation data of a calculated feature that is currently executed. This data is then incomplete and possibly inconsistent (or dirty).
