Manage geodatabase locks

Available with Standard or Advanced license.

Locks are applied to geodatabase objects to help ensure data integrity. For example, if someone is editing the data in a table, a schema lock is placed on the table so the owner cannot change the table's schema while someone is editing the data. Similarly, when someone is editing a feature layer in a branch version, a lock is placed on the version to prevent multiple editors from making edits in the same named version simultaneously.

Which locks you can see from an ArcGIS AllSource client depends on whether you are a dataset or version owner, or the geodatabase administrator. Dataset and traditional version owners can view locks for the items they own; geodatabase administrators can view all locks, including those on branch versions, and disconnect users holding locks when necessary.

Locks view

The Locks view allows you to see the locks applied to enterprise geodatabase objects for which you are the dataset owner, traditional version owner, or geodatabase administrator. Columns for these geodatabase objects reflect the properties of each lock acquired.

These lock properties include the following:

• Object Name—The name of the object being locked.
• Object Type—The type of object, such as a table, feature class, or version that is locked.
• Lock Type—Lock types are used to provide concurrent data access while simultaneously protecting the data. Depending on the registration type of the dataset and the operation, the following lock types can be applied:
  • Schema locks—Used when an operation dependent on the schema of an object is executed. For example, a shared schema lock is acquired anytime a dataset is opened in ArcGIS AllSource. By default, schema locking is enabled on objects locked by services to prevent modifications to the source dataset schemas while the service is running.
  • State locks—State locks are maintained by the enterprise geodatabase when a traditional versioned dataset is accessed to prevent states from being deleted or modified while a client application is accessing or using the state.
  • Version locks—A version lock type is acquired either from editing a traditional versioned dataset from a database connection or from viewing or editing a branch versioned dataset from a service.

    Note:

    Only Version locks acquired from viewing or editing a branch versioned service populate the ExpirationTime, Service Name, and Session ID columns.

  • OID Reservation locks—An OID Reservation lock is acquired when a branch versioned dataset is being edited.

    Note:

    OID Reservation lock types do not include values for the Lock Mode, Time Acquired, or ExpirationTime columns.

• Lock Owner—The user who is accessing or modifying the object that generates the lock.
• Lock Mode—The lock mode determines the type of access permitted for the lock owner and for concurrent users of the locked object. The lock mode differs based on the operation being performed and the versioning type for the dataset. The following lock modes are available in a geodatabase:
  • Shared lock—Operations that allow more than one user to access or read an object require a shared lock. A shared lock prevents any other operation from obtaining an exclusive lock.
  • Exclusive lock—Operations that modify an object (for example, INSERT, UPDATE, or DELETE) and must prevent concurrent users from accessing or updating the object require an exclusive lock. An exclusive lock prevents any other operation from acquiring a lock on that object until the exclusive lock has been released.
• Time Acquired—The date and time the lock was acquired on an object.
• Service Name—The name of the service that caused the lock to be acquired. As stated above, this field is populated for branch versioned services only. Other web services acquire locks on geodatabase objects, but the service names do not appear on this interface.
• ExpirationTime—The date and time the lock will expire. If the lock expires, the lock entry may still be present in the database, though it would not block another lock from being acquired. The lock will be removed from the database once another valid lock is acquired against the version. The lock expiration time is extended while the session is still active.
• Session ID—The client-generated sessionID is a GUID value established for the duration of the session on the version and represents the token used to lock the version.

  Tip:

  ArcGIS Server provides a proprietary token-based authentication mechanism that allows users to authenticate themselves by providing a token instead of a user name and password. An ArcGIS token is a string of encrypted information that contains the user's name, the token expiration time, and some proprietary information.

  Learn more about ArcGIS tokens

View locks on your datasets

If you need to see who is holding a lock that is preventing you from altering the schema of a dataset that you own, you can view a list of the lock held on the dataset on the Geodatabase Administration dialog box.

1. Start ArcGIS AllSource and connect to the geodatabase as the dataset owner.
2. Right-click the dataset in the Catalog pane and click Locks.

   The dataset is listed in the Object Name field, and connections made to the dataset are listed below that.

3. If you need the lock released, either contact the user or users identified in the list and ask them to close their connection to the dataset, or contact your geodatabase administrator.

View locks on your versions

If you need to see who is holding a lock that is preventing you from managing a traditional version that you own, you can view a list of these locks on the Geodatabase Administration dialog box.

Tip:

Only the geodatabase administrator can view locks held on branch versions.

1. Start ArcGIS AllSource and connect to the geodatabase as the version owner.
2. Right-click the database connection in the Catalog pane and click Administration > Locks.

   The Locks list on the Geodatabase Administration dialog box opens, and you can see the locks for datasets and versions you own.

3. If you need the lock released, either contact the user or users identified in the list and ask them to close their connection to the version, or contact your geodatabase administrator.

Manage locks

Geodatabase administrators can see who is holding schema, version, and state locks for all items in the geodatabase using the Locks tab of the Geodatabase Administration dialog box. The geodatabase administrator can also remove the connections that are holding locks to free the resource for use.

Note:

You cannot remove an individual lock; you can only disconnect the user, thereby removing all locks held by that user.

1. Start ArcGIS AllSource and connect to the geodatabase as the geodatabase administrator.
2. Right-click the database connection in the Catalog pane and click Administration > Locks.

   The Locks list on the Geodatabase Administration dialog box opens.

3. Use the drop-down menus at the top to filter locks by object type, object name, lock type, or lock owner.
4. Contact the users who hold the locks that need to be released and ask them to finish their transactions and disconnect from the geodatabase. If someone holding a lock is gone for the day and the lock needs to be released immediately, you can disconnect them.

   Caution:

   Use caution when disconnecting users. Esri recommends that you avoid disconnecting active sessions, especially if the connected user is in the process of editing. You should only disconnect users to drop locks if a session was left open, even when not being used (for example, over the weekend), if a session crashed leaving a connection behind that locks an object, or if a deadlock situation occurs.

5. If necessary, right-click the lock and click Disconnect User.

   The geodatabase administrator requires elevated privileges to disconnect users.

   • In PostgreSQL, the sde user must have superuser status in the database cluster.
   • If your geodatabase in SQL Server is in the sde user's schema, the sde user must have elevated privileges to disconnect users. See Privileges for geodatabases in SQL Server for specific privileges.
   • See Privileges for geodatabases in Oracle for specific privileges needed in Oracle.
   • In SAP HANA, the sde user requires additional database permission. See Privileges for geodatabases in SAP HANA for more information.