branch version locks

[EvaTTA]

Hi,

How does the enterprise gdb register that a branch version no longer has a particular user's shared lock? The context is that the user (i.e. Poster) in charge of posting a branch version back to default is not allowed to reconcile due to the error that the version is still in use. Upon checking the geodatabase administration locks for the enterprise gdb, found out that the version to be posted is held by two users: the Poster and another user, Editor (the owner of the named branch version). However, the Editor mentioned that they have already 'checked out' of their version by changing their named branch back to DEFAULT, as well as removing the layer from their ArcGIS Pro. 

What could be the cause that despite the Editor user disconnecting from their named branch, the enterprise gdb still thinks that the Editor user has a "shared lock" on their named branch, thus preventing the Poster from reconciling and posting the Editor's named branch version back to DEFAULT?

We are working on ArcGIS Enterprise 10.9.1, ArcGIS Pro 3.0.1, and using Microsoft SQL Server 2019 standard edition. 

Thanks

[MarlonAmaya]

Hi @EvaTTA ,

What is the expiration time on the shared lock that is still hold by the Editor? You can see this on the GDB admin locks table. Is the current time past the expiration time?

The act by the user trying to reconcile, should have released the "shared locks" in order to get the exclusive lock. I wonder if we may have an orphaned lock based on the expiration time seen on the GDB locks table.

Marlon

[EvaTTA]

Hi Marlon,

Thanks for the insight about the orphaned lock, I think this is something I need to dive deeper into. When I went to the REST URL for the feature's version (VersionManagementServer), I noticed a REST API called 'purgeLock'. Does this help to remove all orphaned locks? Sadly I did not take note of the shared lock's expiration time for this incident so I can't really provide much info beyond what I've written. 

[MarlonAmaya]

Hi @EvaTTA ,

Purge Locks works the same way as disconnecting from locks tab. Please note that this operation only needs to be done when the lock(s) has been confirmed as an orphaned and/or has not been removed by another lock conflict process that would clean up the lock(s).

https://developers.arcgis.com/rest/services-reference/enterprise/purge-lock.htm

"If there are active edit sessions for the version, all unsaved edits will be lost. The version resource can be reviewed prior to using purgeLock to determine if the version is being edited."

Marlon

[EvaTTA]

Hi Marlon,

Thanks for giving more information on the purgeLock REST API. 

[DrewDowling]

@MarlonAmayaIs it safe to run purge lock against sde.Default? I have just discovered hundreds of shared locks on sde.Default going back over 18 months. No sure why these aren't getting deleted.

[MarlonAmaya]

Hi @DrewDowling 

Are you able to use Pro? Please read the caution detailed in the article below.

https://pro.arcgis.com/en/pro-app/3.0/help/data/geodatabases/overview/manage-geodatabase-locks.htm#:...

Marlon

[DrewDowling]

Yeah I have Pro and have been using that to drop the older ones. Given the number and frequency of these orphan locks I was thinking of scripting a call to the Purge endpoint on the weekends when nobody would be editing, especially not sde.Default. Does that make sense?

We have sde.Default protected so the only time it is edited should be during a post operation.

[MarlonAmaya]

Hi @DrewDowling 

Got it. 

The common workflow is to use a combination of List Users and Disconnect Users python functions

https://pro.arcgis.com/en/pro-app/latest/arcpy/functions/disconnectuser.htm

Are you using ArcGIS Server 10.8.1 or 10.9? If so , do you have this patch installed

https://support.esri.com/en-us/patches-updates/2021/arcgis-server-orphaned-processes-patch-7916

I have not ran purge lock, however based on doc, you can run it on specific versions. Same caution applies as provided in the manage geodatabase locks.

Although orphan locks are possible, if this is occurring repeatedly you may want to submit a support ticket.

Marlon