Knowledge Base - Technical Articles


Technical Article   FAQ:  How are the various lock mechanisms implemented in ArcSDE and the geodatabase?

Article ID: 27034
Software:  ArcGIS - ArcEditor 8.1, 8.1.2, 8.2, 8.3, 9.0 ArcGIS - ArcInfo 8.0.1, 8.0.2, 8.1, 8.1.2, 8.2, 8.3, 9.0 ArcGIS - ArcView 8.1, 8.1.2, 8.2, 8.3, 9.0 ArcSDE 3.0, 3.0.1, 3.0.2, 3.0.2.1, 3.0.2.2, 8.0.1, 8.0.2, 8.1, 8.1.2, 8.2, 8.3, 9.0
Platforms: N/A

Question

How are the various lock mechanisms implemented in ArcSDE and the geodatabase?

Answer

ArcSDE and the geodatabase maintain several types of locking mechanisms for different operations. The locks are managed by persisting rows in tables within the database. Each row is uniquely identified by the process_id. The four locking tables in the sde schema are: table_locks, layer_locks, object_locks, and state_locks.

A description of each lock table and when the locks are acquired is below.

TABLE_LOCKS
Table locks are obtained by the geodatabase when an object class (table) or feature class, or layer, which is a table in its self, are opened by ArcCatalog, ArcMap or referenced by an ArcObjects application. Based upon the operation, a shared or exclusive lock is obtained. Exclusive locks are typically only acquired when the intention is to modify the table's properties. An exclusive lock can only be obtained by the owner of the table and if no shared locks currently exist for the table. As well, shared locks can not be obtained if any exclusive locks are present.

The geodatabase acquires shared table locks when the class is opened to ensure the table's properties do not change. Because the geodatabase caches the table properties within the client application. For example, if a shared table lock was not obtained and the geodatabase had cached a table's properties, if a second session modified the table, the cache would no longer be synchronized with the table. Ultimately leading to various errors when working with the table.

LAYER_LOCKS
Layer locks maintain information for each session which has acquired a full layer shared or exclusive lock and area locks.

The geodatabase only acquires exclusive layer locks on all feature classes participating in a topology when validating a non-versioned topology dataset. Sometimes non-geodatabase applications use layer locks to lock a specific area of a layer to prevent multiple sessions from modifying the features within the specified envelope. Again the application determines if the lock type should be shared or exclusive.

OBJECT_LOCKS
Object locks are an application maintained locking mechanism exposed by ArcSDE.

The geodatabase uses object locks to acquire shared and exclusive locks on version objects during editing and reconciling. The geodatabase acquires a shared object lock for a session on start editing. Because the lock type is shared, multiple sessions can edit the same version simultaneously. When a session starts a reconcile, the shared locked is promoted to an exclusive lock, succeeding only if no other shared locks are present. Promoting the shared lock to exclusive ensures no other sessions are currently editing and no sessions can start editing while the reconcile proceeds. The lock is not released until the post operation or stop editing.

STATE_LOCKS
State locks are maintained by ArcSDE to prevent states from being deleted or modified while a client application is accessing or using the state. States can be locked in shared or exclusive mode.

The geodatabase acquires exclusive state locks for the new state during each edit operation. The exclusive lock prevents the state from being deleted or trimmed if the compress operation is executed. The lock is released by the geodatabase on the stop editing event.

The ArcSDE server configuration parameter stateautolocking controls if ArcSDE automatically applies shared state locks for applications which have not explicitly set a state lock when accessing the state. By default, the parameter is disabled, implying no auto locking will take place. This improves application performance and database scalability.

It is not recommended that any lock tables are modified directly with SQL. Removing or changing lock values can potentially lead to application errors and data corruption. ArcSDE maintains these locks and validates if locks are valid when a lock collision is encountered. An example of a lock collision is when one session attempts to acquire an exclusive lock when shared locks are present.

Each ArcSDE DBMS implements lock collision validation differently and therefore is not explained in this knowledge base document.

Created: 6/18/2004
Last Modified: 5/22/2006

If you would like to post a comment, please login

Comments

By Anonymous - 08/26/2009 7:37 AM

The article needs to be updated.

How does this article apply to the newer versions of ArcSDE?