Locks left on shapefiles when using SelectLayerBy tools

[JimDetwiler1]

I recently switched from Desktop to Pro and have run into a problem with locks being left on shapefiles when I use SelectLayerByAttribute or SelectLayerByLocation.  Both the Desktop and Pro documentation show the same stand-alone script for both tools, though the Pro version of the script is a bit different. 

DESKTOP:

env.workspace = "c:/data/mexico.gdb"

# Make a layer from the feature class

arcpy.MakeFeatureLayer_management("cities", "lyr")

# Select all cities which overlap the chihuahua polygon

arcpy.SelectLayerByLocation_management("lyr", "intersect", "chihuahua", 0, "new_selection")

PRO:

arcpy.env.workspace = 'c:/data/mexico.gdb'

# Select all cities which overlap the chihuahua polygon

chihuahua_cities = arcpy.SelectLayerByLocation_management('cities', 'INTERSECT', 'chihuahua', 0, 'NEW_SELECTION')

The Desktop sample shows using MakeFeatureLayer to create a feature layer out of the cities feature class, then passing that as the first argument to the SelectLayerByLocation tool.  The Pro sample doesn't bother to create a feature layer first; it simply plugs in the feature class ('cities').   The Pro sample also shows storing a returned object in a variable (chihuahua_cities). 

When I've used these tools on shapefiles in Desktop, I've always used MakeFeatureLayer as shown in the sample.  It places a lock on the shapefile, but I can remove the lock by using Delete when I'm done (in this case, I'd do arcpy.Delete_management("lyr")). 

When I try to follow the syntax shown in the Pro help (storing the returned object in a variable), I also get a lock placed on the shapefile, but I haven't found a way to remove the lock aside from closing my IDE.  I've tried:

arcpy.Delete_management(chihuahua_cities)

arcpy.Delete_management(chihuahua_cities[0])

But neither actually removes the lock.  I can continue to code it the way that's shown in the Desktop help, but was wondering if there was a fix to the problem that follows the syntax shown in the Pro help.

Thanks!

[DanPatterson_Retired]

well I just finished 30+ years of teaching... so enjoy!

  I think the file size of 0 bytes is important and that i could repeat the selection that it is benign.  The help files contain information on when a lock is an issue and for the most part, it is the "sharesies thing" with multiple people potentially using the same data. I also think python might be done with "arc stuff" when you delete it and it is garbage collected... but that doesn't mean that arc is done with python until you kill the python thread that is running then there is nothing left to hand on to.

[MichaelWallace3]

@JimDetwiler1  thanks for posting this issue report and @DanPatterson_Retired  for confirming the behavior. For reference I created a script tool to iteratively do select by location so that I could attribute features that were connected together. This script works fine in the python command line in pro, but run as a script tool it will run once and then I can't select any other features afterwards. Resolution so far has been to shutdown and restart Pro.  I don't know if someone could look at this issue again and maybe create a suitable resolution to kill the lock on the selected object? If not at least thank you for explaining all of this.

[Adrian]

Left behind locks are a big issue within arcpy and we struggle with that almost every day. There are several arcpy functions which are not cleaning up lock files, respectively the resources are only unlocked after the Python process terminates. This is cumbersome, not best practise and results in many problems. For example serially running geo processing tools can stumble across lock files from previous steps. Moving or deleting the processed data afterwards is not possible with locks.

A few months ago, we tried to explain the general problem to Esri support with a ticket and a simple use case:

arcpy.Exists(path/to/a/gdb)

shutil.rmtree(path/to/a/gdb)

 The code fails because of locks (PermissionError), which is not expected.

The answer from Esri support showed us, that the message of this general problem has not been received: "When this script is run it fails on "shutil.rmtree(path/to/a/gdb) [...] It would not be considered an Esri product in what we are responsible for. [...] When the python process is closed the lock goes away."

So we remain stuck with our workaround to use the multiprocessing library of Python to run affected arcpy functions in separate processes. Because these separate processes terminate, the lock files are cleared and the main process can go on without any problems.