Updating Branch Versioned Feature Layer Fails w/ Lock Acquisition Exception

[__JackCharde__]

I have a script that is attempting to edit branch versioned data with the Python API and I am encountering an error I don't really understand.

The essential parts of the script are below:

gis = GIS(portal_url, creds.username, creds.password)
vm_url = test_svc_url.replace('FeatureServer', 'VersionManagementServer')
version_mgr = VersionManager(vm_url, gis)
version = [v for v in version_mgr.all if v.properties['versionName'].lower() == version_name.lower()][0]
addr_pt_fl = version.layers[addr_pt_lyr_id]

# Only return FeatureSet of features that need to be updated
addr_pt_fs = addr_pt_fl.query(where=where, out_fields=['OBJECTID','ADDRAPNID','APNID'], return_geometry=False)

# Code here updates some attributes in the addr_pt_fs FeatureSet to apply to the version

try:
    version.mode = 'edit'
    version.save_edits = True
    result = version.edit(addr_pt_fl, updates=updated_features, rollback_on_failure=True)
    version.mode = 'None'
    print(result)
except Exception as e:
    print(str(e.args))

Now at first I tried using version.start_editing() because it's supposed to set the mode so that when .edit() is called (which checks the mode), it would succeed. I watched my debugger as .start_editing() switched mode to read, then edit, then None. Not sure why that was happening, so I switched to calling the mode setter, which appropriately set the mode to edit. I thus assumed the edit would work. I'm receiving the following error now:

('Unable to complete operation.\nError: Cannot acquire a lock.\n(Error Code: 500)',)

I don't know how it wouldn't be able to acquire a lock when this version is private, only I can access it, and there were no locks on it. I even verified the locks list on the VersionManager object and there were none. I also know there were none because I specifically called VersionManager.purge() with my admin credentials to remove locks that were created when I tried both version.mode = 'edit' and version.start_editing().

What's also annoying is that when the VersionManager says there's a lock on my version, I see isLocked, isBeingRead, and isBeingEdited are all True, so I assume there's an exclusive lock on it. However, when I try to run version.mode = 'None' which should terminate the session and release the lock, it does not, saying:

('Object has no schema locks.\n(Error Code: 0)',)

so I have to run the admin method I previously described to purge the lock.

Does anyone have any insight into what I'm doing wrong? Thanks in advance

- Jack C

[KenGalliher1]

Give one or both of these a try:

When using the Version object, use the context manager with the "read" argument, then set the mode to "edit" inside. This will help manage the starting and stopping of the edit session automatically. The initial "read" session will acquire shared locks on the version and "edit" will apply the exclusive locks.

with version_mgr.get(version_name, "read") as version:
    version.mode = "edit"
    res = version.edit(fl, updates=edit_feature)
    print(res)

Usually (not always) the error "Object has no schema locks" means the edit session either didn't start or there is an old edit session still open. You are using purgeLock to fix that which is correct. The error "Cannot acquire a lock" means there is an open edit session. This is where the context manager should help. Upon exiting, it should stop any open read and/or edit sessions with that session ID.

Alternatively, try using the edit_features method in the FeatureLayer object by passing in the version name string.

fl.edit_features(updates=[edit_feature], gdb_version="owner.version_name")

Editing Features | ArcGIS API for Python

[__JackCharde__]

Hey @KenGalliher1,

Thanks for this info. I attempted to use both approaches, and both returned the "can't acquire a lock" error. There is not a single other place that the version is open elsewhere, and when I first instantiate VersionManager, I can verify the locks list is empty.

To verify there wasn't just something going on with the version I was using, I tried the same thing with a new version, to the same end.

[KenGalliher1]

What version of Pro and Python API are you using? Some changes went in last August that help the API better manage version locking.

[__JackCharde__]

I'm actively working on updating these. I just updated Pro to 3.2.4, as the client's enterprise environment was just upgraded to 11.2. The Python API is currently at 2.0.1, which is about 3 years old now.

This client's main Python environment (which includes arcpy and arcgis) was created and is maintained outside of Pro (via Anaconda Navigator) and we're having some issues upgrading it all. But once it is, I'll try this all again, and hopefully, the newer API version will alleviate the roadblocks.

[__JackCharde__ · Accepted solution]

@KenGalliher1updating my Python environment solved my issues. The new environment (external to Pro) was updated to match what is needed by Pro 3.2, so the API library version is now 2.2.0.3.

I also employed a generator function to iterate my original dictionary of features ID'd for an update so that I could break the whole update into manageable chunks (500 records at a time), and the script acquired and released the exclusive lock each time w/o issue.

Thanks again for your assistance and suggestions!

- Jack C