File Geodatabase Problem(s)

[SteveMlinarich]

Correct me if I'm wrong, but one of the advantages of File Geodatabases is that it can be edited while another user is viewing it. However, it has been my experience that this isn't the case all the time. Sometimes it works fine and other times it will not work properly (randomly). Has anyone else run into this problem? This has been the case in 9.2 and 9.3. Also, on another note certain users locks will hang for months even with regular compacting of the geodatabases. I've searched and searched and have found nothing on the editing/viewing problem and very little on getting the hanging locks fixed. If anyone has any advice, opinions, etc. it would be greatly appreciated.

Thanks!

[LanceShipman]

Correct me if I'm wrong, but one of the advantages of File Geodatabases is that it can be edited while another user is viewing it. However, it has been my experience that this isn't the case all the time. Sometimes it works fine and other times it will not work properly (randomly). Has anyone else run into this problem? This has been the case in 9.2 and 9.3. Also, on another note certain users locks will hang for months even with regular compacting of the geodatabases. I've searched and searched and have found nothing on the editing/viewing problem and very little on getting the hanging locks fixed. If anyone has any advice, opinions, etc. it would be greatly appreciated.

Thanks!

The only time that there should be an issue with viewing data when it is being edited by another user is during save edits, otherwise there should be no problems.

Normally compact will remove hanging locks, so I'm not sure what is happening in your case. You can delete the locks from windows explorer, but be careful to not delete anything else. Can you zip up an example and post it?

[SteveMlinarich]

The only time that there should be an issue with viewing data when it is being edited by another user is during save edits, otherwise there should be no problems.

Normally compact will remove hanging locks, so I'm not sure what is happening in your case. You can delete the locks from windows explorer, but be careful to not delete anything else. Can you zip up an example and post it?

If someone just has the feature class in their .mxd for viewing another person can not even start an edit session. I did notice in 9.3 shapefiles could be edited and overwritten while another user has it open (basically behaving the way the FGDb should). Am I understanding your response correctly in that one person can view and another can edit, however when it comes time to save the edits only the editor can have the FGDb open and if it is being viewed by another user at the time of saving edits the editor will not be able to save?

[LanceShipman]

Am I understanding your response correctly in that one person can view and another can edit, however when it comes time to save the edits only the editor can have the FGDb open and if it is being viewed by another user at the time of saving edits the editor will not be able to save?

The editor will be able to save even if another user is viewing the data. The reader may get a locking error if they refresh during the save. A subsequent refresh will work correctly.

If someone just has the feature class in their .mxd for viewing another person can not even start an edit session. I did notice in 9.3 shapefiles could be edited and overwritten while another user has it open (basically behaving the way the FGDb should).

This behavior is not consistent with the design and I have not seen it using any version of ArcGIS. It works the same for File Geodatabase as it does for shapefiles. You should call technical support and work through this with them.

[karisamurphy]

I am having similar problems saving edits while another views. Nearly every time I edit I get one of two errors: can�??t acquire a lock, or the index is too large or small. However, my partner is not having this issue.  If someone could help shine some light on this it would be great, because I�??ve already tried tech support and obviously their support only goes so far.

[LanceShipman]

Can you send me your support incident number (lshipman@esri.com). Reviewing it will save coving the same ground all over again.

[MichaelVolz]

Was there ever a resolution to this problem?  I am having file geodatabase locking issues as well and the solution here might shed some light on my problem.

[KevinClarke1]

I am encountering locking issues with a Mosaic Dataset stored within a file gdb.  With ArcGIS Server 10.0, I am attempting to start an image service for the mosaic dataset.  The image service parameters are set to Pooled with min 50 and max 75 instances with Low
Isolation and 25 instances per process, thus resulting in initially 2 and a max of 3 SOC.exe processes being created.

I have around 50 image services configured with these parameters, and about another 50 configured with lower min/max and instances per process values. Each of the 50 services accesses a mosaic dataset in a different file geodatabase.

When restarting the ArcGIS Server services or rebooting the server as a means of restart the image services do not restart automatically as is the case for single threaded/High Isolation configured services.

After attempting to start the services manually (after they did not start up automatically) I receive the following error, which I assume is the same reason the services are not starting automattcally.

Server Object instance creation failed on machine <xxxmymachinexx>.
Cannot acquire a lock. [The table GDB_Items is being written by another process.]
The table was not found. [tx_2012]

Where tx_2012 is the name of the mosaic dataset.

Is there a limit on the number of threads that an ArcGIS Server image service can issue/hold against a mosiac dataset in a file gdb??

[MichaelVolz]

"I am encountering locking issues with a Mosaic Dataset stored within a file gdb. With ArcGIS Server 10.0, I am attempting to start an image service for the mosaic dataset. The image service parameters are set to Pooled with min 50 and max 75 instances with Low
Isolation and 25 instances per process, thus resulting in initially 2 and a max of 3 SOC.exe processes being created."

Why do you have such high min and max number of instances?

Also, why do you have the instances running in low isolation?

[KevinClarke1]

"I am encountering locking issues with a Mosaic Dataset stored within a file gdb. With ArcGIS Server 10.0, I am attempting to start an image service for the mosaic dataset. The image service parameters are set to Pooled with min 50 and max 75 instances with Low
Isolation and 25 instances per process, thus resulting in initially 2 and a max of 3 SOC.exe processes being created."

Why do you have such high min and max number of instances? 

Also, why do you have the instances running in low isolation?

You make it sound as if the Low Isolation configuration should not be used. Why does AGS support the ability to multithread inside the SOC process - to allow more simultaneous connections while keeping the number of SOCs reduced and thus consuming less RAM.

The documentation states that up to 255 service instances can be hosted within a SOC, so 50 - 75 is not considered a high number. Spinning up 75 single threaded SOCs (high isolation) consumes about 4GB of RAM, before the bloating/leaking of the SOCs takes place over the course of the day as they are used over and over Until the nightly recycle resets them back to the 50MB of RAM usage). So using low isolation would stil lallow 75 concurrent connections to a service buy do it with just 1 or 2 SOCs costing 100MB RAM, so substantial savings.

Anytime I have set more then 3 or 4 image services (out the 100 or so I need to spin up) with low isolation architecture, they never start up properly even with the default of 8 instances per SOC, and that coupled with the locking issues I originally stated as the problem I was seeing, may cause me to abandon any configurations set up with low isolation for a high capacity (1 million hits per hour) environment.