Crash when creating geodatabase after closing deleting a geodatabase

[PaulAustin]

In my App (Java with swig bindings to the API) I create 3 geodatabases. Make some changes to them. Commit those changes to a real database. Then I close the geodatabases and create a new one. I get the following exception running on Windows Server 2008 64 bit running a 32bit app compiled using Visual Studio 2008. I don't get the error on Windows 8 or Mac OS X Lion.

C  [ntdll.dll+0x38e19]  RtlIntegerToUnicodeString+0x2fc
C  [ntdll.dll+0x38d28]  RtlIntegerToUnicodeString+0x20b
C  [FileGDBAPI.dll+0xe7aff]  FileGDBAPI::Envelope::~Envelope+0x687df
C  [FileGDBAPI.dll+0x372a1]  FileGDBAPI::SpatialReferences::FindSpatialReferenceByName+0x21071
C  [FileGDBAPI.dll+0x2271]  FileGDBAPI::FieldInfo::FieldInfo+0x861
C  [FileGDBAPI.dll+0x5d1e]  FileGDBAPI::Geodatabase::CreateGeodatabase+0xce
C  [FileGDBAPI.dll+0x8f1f]  FileGDBAPI::CreateGeodatabase+0xf

[PaulAustin]

Further to this it is now occurring on all platforms.

It looks like if I call DeleteGeodatabase then it will crash when I try and create a new one. The geodatabase was closed when calling delete.

[PaulAustin]

I think this is related to the following issue which talks about thread safety.

http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit-Linux-when-same-File-Geodatab...

In my application which is written in Java with a Swig binding to the API I use threads extensively.

I had synchronized access to the geodatabase objects so that only one thread could concurrently be accessing that geodatabase and any tables, rows etc created from it. Then I had a separate synchronization on the access to the API to create/open/delete geodatabases. I hadn't thought that once I had a geodatabase open that I'd have to synchronize everything to create/modify tables or anything else hidden in the API that used XML. I'm sure now this is the cause of the problem.

[RANT]I find it kind of crazy that an XML library forces everything to be single thread. Is there not a way to create a new instance of the XML parser per thread to avoid this.[/RANT]

I can understand that for a given table or for management of the database that synchronization is a good idea. However the fact that there is no option for concurrency across any open geodatabases in the same application makes the performance of an application suck. For example I have code where I want to read data from 30 tables and insert them into an Oracle database. In theory I should be able to run that all in parallel, even on a 4 core machine you'd get a lot of concurrency while some threads are blocked for database IO. But when using non-threaded libraries that have every call synchronized that puts a throttle on concurrency as threads will be waiting on monitors most of the time.