File geodatabase lock files are not automatically deleted since ArcGIS Pro 3.5

[ljlopez]

Hi all,

I have an ArcGIS Pro add-in that has been working on all 3.x versions of ArcGIS Pro but fails on 3.5. Its code creates a File Geodatabase, imports some feature classes, and then creates a zip file of the File Geodatabase. Since version 3.5, the creation of the zip file fails with the following error message:

The process cannot access the file {path_to_geodatabase}.gdb\a0000000d.gdbtable because it is being used by another process

The File Geodatabase and all its feature classes are successfully created, and the code uses using statements for the geodatabase, feature classes, insert cursors, etc., so that they are all properly disposed. Also, the code is called on the Main CIM Thread (MCT) using QueuedTask.Run().

I noticed that since 3.5 two lock files are kept inside the File Geodatabase folder, and they are not automatically deleted no matter how much time you wait. This did not happen with earlier versions of ArcGIS Pro.

Has a new behaviour regarding File Geodatabase locking or the MCT been introduced in 3.5? Is there a way to remove programmatically the lock files, or make sure that the process terminates appropriately using the ArcGIS Pro SDK for .NET?

[Aashis]

@ljlopez We haven't changed the behaviour for File Geodatabase. If possible, could you pls send your code? We'd love to investigate it. 

[Wolf]

I made a small sample add-in that imports a csv (included as add-in content) and adds the data into a new feature class in your project's default geodatabase.   To run the add-in start with a new [empty] map [template] and open the 'FGB Importer' tab.  Click the 'Show FGB Importer' button to open the Importer dockpane.  On the dockpane all paths etc. should be filled in.  Just click the 'Import into F/C' button.  This will create a new feature class in the given geodatabase and then adds the csv data to that feature class. 
Maybe i left out something in my code, but i also have the remaining .lock file in my geodatabase folder.  I am currently running 3.6 but i will try 3.4 tomorrow.
I will add this code to the community samples with the 3.6 release, it hasn't been fully debugged.

[Wolf]

I tried this Addin using ArcGIS Pro 3.4 and i see the .lock files in 3.4 as well.   As far as i can tell, the geodatabase connection must still be open.   I think the same happens when you use the Catalog dockpane and manually open the Geodatabase:  a .lock file is created and stays until you close Pro.  I don't see a change in behavior between 3.4 and 3.5.   

[ljlopez]

@Aashis, @Wolf, thank you both for your responses. I have been able to narrow down the problem. It turns out that if GetFields() is called on an instance of FeatureClassDefinition, then lock files are left inside the file geodatabase folder unless the instance of FeatureClassDefinition is disposed. Is this the expected behaviour or a bug? I have tested the code below with different versions of ArcGIS Pro and I can confirm that the issue was introduced in 3.5.

// With this code lock files are left inside the file geodatabase folder.
var def = featureClass.GetDefinition();
var fields = def.GetFields();

// With this code the lock files are automatically removed. 
using (FeatureClassDefinition def = featureClass.GetDefinition())
{
    var fields = def.GetFields();
}

I have also noticed that the same issue occurs if calling GetSpatialReference(). However, NO lock files are left behind if calling other methods of the FeatureClassDefinition class, such as GetIndexes(), GetSubtypes(), or GetObjectIDField().

[Aashis · Accepted solution]

The Pro SDK Core.Data API uses unmanaged resources (i.e., resources not managed by garbage collection), which must be explicitly released by the application. Unmanaged resources include file locks, database connections, and network connections, amongst others.

The using statement ensures that a disposable instance is disposed even if an exception occurs within the block of the using statement. In the above example, line #1: feature class definition is not disposed, so it is holding the lock. However, in line # 6, the feature class definition is disposed after all lines are processed, so the lock is removed. Please refer to the Geodatabase Resource Management doc for additional details on SDK garbage collection and resource management.

We recommend disposing of the field list in line #8 as below

foreach (var field in fields)
{
    field.Dispose();
}

[ljlopez]

Thanks for your answer, @Aashis. Yes, no problem with getting my code fixed. I was just making the point, in case the change in behaviour was not intended and therefore was a bug, that with version 3.4 and earlier a call to GetFields() seemingly does not add lock files as disposing is not necessary, while with 3.5 and 3.5.1 the lock files are created and disposing is mandatory.