topic Re: Clarifying when cursor locks are released in Python Questions

Clarifying when cursor locks are released

KerryAlley — Tue, 12 Mar 2013 13:53:03 GMT

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)

Re: Clarifying when cursor locks are released

MathewCoyle — Tue, 12 Mar 2013 15:17:37 GMT

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.

Re: Clarifying when cursor locks are released

LucasDanzinger — Tue, 12 Mar 2013 15:22:19 GMT

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.

Re: Clarifying when cursor locks are released

MathewCoyle — Tue, 12 Mar 2013 15:32:36 GMT

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?

Re: Clarifying when cursor locks are released

LucasDanzinger — Tue, 12 Mar 2013 15:43:08 GMT

Yeah, I just entered it last week, so it usually takes a few days.

Re: Clarifying when cursor locks are released

MichaelVolz — Tue, 12 Mar 2013 15:44:32 GMT

"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?

Re: Clarifying when cursor locks are released

KerryAlley — Tue, 12 Mar 2013 16:58:32 GMT

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

Re: Clarifying when cursor locks are released

MathewCoyle — Tue, 12 Mar 2013 17:06:07 GMT

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')]

Re: Clarifying when cursor locks are released

LucasDanzinger — Tue, 12 Mar 2013 23:44:42 GMT

"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.

Re: Clarifying when cursor locks are released

LT — Wed, 03 Apr 2013 14:42:09 GMT

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

Re: Clarifying when cursor locks are released

MathewCoyle — Wed, 03 Apr 2013 15:29:36 GMT

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

You can search for bugs that have been published here.

http://support.esri.com/en/

This one still isn't showing up though. I assume Esri has internal bug tracking that they don't publish immediately, or ever, as I have seen numerous NIM references from Esri support that don't ever show up there under the referenced number.

Re: Clarifying when cursor locks are released

LT — Wed, 03 Apr 2013 17:37:00 GMT

thanks, Mark. I'm feeling a bit concerned about it not showing up. Could this mean that it's not going to be considered as a bug? I've had several interactions with some Esri folks about this and they pointed out that if you run a script from the command line (or double click it to run in directly with python.exe), this bug doesn't occur. Or if you run it in Pyscripter this bug doesn't occur. So one suggested solution was to switch IDE's --sort of implying that this wasn't really a bug. They pointed out several special cases where all the locks ARE deleted. They said they'd change the documentation to match the current behavior--but they never agreed that the behavior needed to change.

This bug even occurs within the ArcGIS Python window, for heavens sake. So...I'm hoping it will get attention very soon.