Clarifying when cursor locks are released

1968
11
Jump to solution
03-12-2013 06:53 AM
KerryAlley
Occasional Contributor
Does the following line of code "release" the cursor? 
#Note: rdsmall_lyr has a single selected feature rdsmall_values = sorted(arcpy.da.SearchCursor(rdsmall_lyr, ["UA", "FAID_S", "CTCODE", "RTNUMBER", "AOTCLASS"]))

The help pages state that a cursor can be released by the completion of the cursor (http://resources.arcgis.com/en/help/main/10.1/index.html#//002z0000001q000000), but I'm not very confident in my understanding of an implicit release.  Any insight would be greatly appreciated! 
I do have an alternative approach that I'm confident tidies up after itself (below), but am hoping I can get away with the simpler code.
with arcpy.da.SearchCursor(rdsmall_lyr, ["UA", "FAID_S", "CTCODE", "RTNUMBER", "AOTCLASS"]) as road_cur:     rdsmall_values = sorted(road_cur)
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
MathewCoyle
Frequent Contributor
The '__enter__' and '__exit__' methods were added to the da cursors to help with locking issues. They are most easily and explicitly accessed via the with statement which is the preferred method of opening and closing da cursors.

That being said, your code should be releasing the locks immediately after it runs, assuming there were no other errors.

View solution in original post

0 Kudos
11 Replies
MathewCoyle
Frequent Contributor
The '__enter__' and '__exit__' methods were added to the da cursors to help with locking issues. They are most easily and explicitly accessed via the with statement which is the preferred method of opening and closing da cursors.

That being said, your code should be releasing the locks immediately after it runs, assuming there were no other errors.

View solution in original post

0 Kudos
LucasDanzinger
Esri Frequent Contributor
The second statement should release the locks automatically, but there appears to be a bug with this- NIM089529: The data access arcpy cursors do not release locks when using with statement. Otherwise, an easy thing to do to see if it is working is to just watch your workspace in Windows Explorer and see if you see either a shared or exclusive lock file is being applied. They should be pretty easy to spot and will show up as a data type of LOCK.
0 Kudos
MathewCoyle
Frequent Contributor
The second statement should release the locks automatically, but there appears to be a bug with this- NIM089529: The data access arcpy cursors do not release locks when using with statement. Otherwise, an easy thing to do to see if it is working is to just watch your workspace in Windows Explorer and see if you see either a shared or exclusive lock file is being applied. They should be pretty easy to spot and will show up as a data type of LOCK.


Oh yeah look at that. Never noticed that issue before. Deleting the cursor object gets rid of it though.

Edit: I can't seem to be able to find the NIM entry on the support page though. Is it new?
0 Kudos
LucasDanzinger
Esri Frequent Contributor
Yeah, I just entered it last week, so it usually takes a few days.
0 Kudos
MichaelVolz
Esteemed Contributor
"Otherwise, an easy thing to do to see if it is working is to just watch your workspace in Windows Explorer and see if you see either a shared or exclusive lock file is being applied. They should be pretty easy to spot and will show up as a data type of LOCK."

Would this method of spotting lock files only apply to shapefile, personal and file geodatabases?

Would you need to worry about locks from arcpy.da if you are working with an SDE geodatabase that is built to accomodate multiple users?
0 Kudos
KerryAlley
Occasional Contributor
Thanks mzcoyle and ldanzinger!

Thanks for the tip about using Windows Explorer to monitor locks.  It helped me confirm that my first line of code releases the lock, and that using the "with" statement does not.

Just a little note about using Windows Explorer to monitor locks:  Since I'm using arcpy.mapping (layer and map document classes as well as cursors) it's difficult to use Windows Explorer to tell when .sr.locks are added/removed.  However, even though the lock files don't appear to update in Windows Explorer as additional locks are added/removed, I could isolate/confirm an arcpy object with a lock by deleting all other arcpy objects that could have locks, and watch the .lock files disappear as I then deleted the arcpy object of interest.

Either of you know who might have answers to my other question?
http://forums.arcgis.com/threads/79642-Setting-workspace-to-SDE-feature-dataset
0 Kudos
MathewCoyle
Frequent Contributor
This may be one way, just came up with it and it is pretty untested, though gives more or less right results for me.

lock_list = [item.split('.')[0] for item in os.listdir(your_gdb) if item.endswith('.lock') and not item.startswith('_gdb')]
0 Kudos
LucasDanzinger
Esri Frequent Contributor
"Otherwise, an easy thing to do to see if it is working is to just watch your workspace in Windows Explorer and see if you see either a shared or exclusive lock file is being applied. They should be pretty easy to spot and will show up as a data type of LOCK."

Would this method of spotting lock files only apply to shapefile, personal and file geodatabases? 

Would you need to worry about locks from arcpy.da if you are working with an SDE geodatabase that is built to accomodate multiple users?


It will work well for shapefile and file gdb. Personal geodatabases are a bit different, as locks occur at the geodatabase level. However, you can see the locks on the entire mdb. I only tested the "with" bug on a file gdb, but I imagine the input data type shouldn't make a difference. I would say regardless of what database you are going through and regardless of what technology you are using to do a cursor (i.e. whether through arcpy or not), you should always remove the locks to take them out of memory.
0 Kudos
LT
by
Occasional Contributor
Edit: I can't seem to be able to find the NIM entry on the support page though. Is it new?


Is there a place to track updates on bugs if we know the number?   I'm very interested to see what's going to happen with NIM089529

Apologies if this is stupid questions.  I did try googling it for a while, but no luck yet.

Thanks
0 Kudos