Edit operation failed. Message: Cannot acquire a lock.

[AmyRoustCoL]

I've taken the instructor-led classes on Utility Networks and done tons of tutorials, but I still find it difficult to troubleshoot errors. Has anyone ever seen this error? I realize the image is really small. The red box says, "Edit operation failed. Message: Cannot acquire a lock."

The user is editing on a version and just randomly gets this error from time to time. Our previous editing service was so buggy that I published a brand new one. This error pops up on the new one. 

We have a ticket in with Esri support because his versions won't reconcile with DEFAULT. I don't have that problem, so it's even stranger that one user would have the issue and I don't. Granted, I am an admin and he isn't, but there's just so little to go on that I'm grasping at straws.

[RobertKrisher]

When this happens you should look at the locks in the database and see who else has a lock on that version. Read the Manage geodatabase locks topic in the online help to learn more.

[HusseinNasser2 · Accepted solution]

This particular error (cannot acquire a lock) occurs when you try to edit a version while another user is reading the same version (often from Pro). Which we did not allow prior to 12.1. 

Starting with 12.1, multiple users will be open and view the same version but only one can edit it.

Jargon mode activated: When Pro is switching to a version it calls startReading on the version to acquire a read lock. When another user switches to the same version they also call startReading to acquire another read lock on the same version, multiple read locks were always allowed. When the first user attempts to edit Pro calls startEditing to promote its read lock to write lock which is now allowed in 12.1 where it used to fail before because of an existing read lock.

Prior to 12.1 only single writer no readers are allowed, with 12.1 single writer, multiple readers allowed.

What to do? ask the admin to call purgeLock on the rest end point to purge all readers on that version, beware that this will toss any unsaved edits.

[PierreloupDucroix]

Hello,

You indicated that the first edit attempt would trigger the `startEditing` call, but when is `stopEditing` called once the user has finished editing?

I'm trying to find out if it would be possible (in version 12.1 or earlier) for multiple users to take turns editing the same version in ArcGIS Pro or the Web Editor.

Another use case would be parallel editing by a user in Pro and by a toolbox, also in Pro. Currently, it seems that using a toolbox to edit a version cannot benefit from the lock of the logged-in user.

[HusseinNasser2]

StopEditing is called when the user clicks the save edits or discard button in Pro. This demotes the write lock back to a read lock, allowing another user with a read lock on same version (again in 12.1) to edit the version. I would watch out however for Pro's feature cache.

The case of a toolbox or an Add-in Pro is different. Both the add-in and Pro use the same user identity, but different session Ids. That is because the add-in doesn't have access to the sessionId used by Pro on start up. This is effectively the same case as if two Pro sessions logged in with the same user on same version. The server treats the second session Id as if the user has crashed and came back with a new session id effectively wiping all the locks obtained by the first session id. 

[PierreloupDucroix]

So you're confirming that:

- it's impossible to access the session ID of an active user and use it to pass to a Python toolbox to edit the current version (using the class `arcgis.features._version.Version(url, flc=None, gis=None, session_guid=None, mode=None)`)?

- but that the second session ID (sent by the toolbox) should be treated by the server as a new session for the same user, thus releasing the locks from the previous session?

Because we consistently get an "Object has no schema lock" message in the second case.

[HusseinNasser2]

That is correct, there is no way to access the current Pro user session Id for now. So the toolbox is treated as a new session id. A null/empty session id just means the server will generate a new one.

The object has no schema lock tells us that the lock for the first session Id has been purged by the user's new session id. So the applyEdits with the first sessionId fails with object has no schema locks.

The safest thing to do in the case where there are tools trying to edit a version with Pro is to always save the edits prior to running the tool. You can have the python tool check `isBeingEdited` property on the version and fail if it is true, display an error message forcing the user to save/discard their edits. This way, Pro will call stopEditing. Of course when the python tool runs it wipes Pro's lock, but that is ok, because in the next edit Pro will call startEditing with the first session Id and obtain the write lock back.

Hope that helps

[PierreloupDucroix]

In the scenario you described, when the user saves their changes, the `stopEditing` function is called, but the user is still in read mode. If I understand correctly, prior to version 12.1, the toolbox couldn't acquire a new edit lock for the reasons you mentioned earlier (because of an existing read lock)?

Is there a way to achieve this in version 11.5 without purging the read locks?

Would it be possible to contact you privately to discuss this further?