- Direct Known Subclasses:
- WFSTLockFeatureRequest1_0_0
public abstract class WFSTLockFeatureRequest
extends WFSRequest
Web connections are inherently stateless. As a consequence
of this, the semantics of serializable transactions are not
preserved. To understand the issue, consider an update operation.
The client fetches a feature instance. The feature is then
modified on the client side, and submitted back to the database
via a Transaction request for update. Serializability is lost
since there is nothing to guarantee that while the feature was
being modified on the client side, another client did not come
along and update that same feature in the database.
One way to ensure serializability is to require that access to
data be done in a mutually exclusive manner; that is while one
transaction accesses a data item, no other transaction can modify
the same data item. This can be accomplished by using locks that
control access to the data.
The purpose of the LockFeature operation is to expose a long
term feature locking mechanism to ensure consistency. The lock
is considered long term because network latency would make
feature locks last relatively longer than native commercial
database locks.
The LockFeature operation is optional and does not need to be
implemented for a WFS implementation to conform to this
specification. If a WFS implements the LockFeature operation,
this fact must be advertised in the capabilities document
- Author:
- Jorge Piera LLodrá (jorge.piera@iver.es)
- See Also:
http://www.opengeospatial.org/standards/wfs