We have a web application that is using a custom SOE that we have written. Inside of this SOE we do alot of editing to a versioned database.
There are many edits that are concurrently being made to the same version so we have implemented a Mutex in .NET to prevent concurrent calls to StopEditing. Since the mutex doesn't not wrap the Start editing calls we often get the error on stop editing that the version is redefined. This is to be expected and we do a reconcile and call stop edits again. After this is done we exit the mutex and the next thread that is waiting to save their changes gets it's turn.
For 99% of the cases this all works correctly. However, one of our customers is REALLY hitting the server and somehow this seems to not be working all of the time anymore. With logging it still appears that only a single process is entering the Mutex, but we often get an error when performing the Reconcile that it could not be completed because another process was reconciling against the target ersion.
There are no ArcMap users. All data editing is going through our SOE, so the only way for a reconcile to occur is through our SOE code. I've made sure that there is only a single location that calls Reconcile.
So, my question is whether or not their is anything else in ArcObjects that perhaps causes database locks that the Reoncile call would interpret as a reconcile already being performed?
My only thought was that we call IVersion.RefreshVersion() quite often to make sure the current workspace/feature classes are pointing at the latest data. Logically refresh version behaves very similarly to a reconcile, but I wouldn't think it would cause any locks to be generated.
Any thoughts on other ways that we could be making Reconcile think a reconcile is already occurring when it isn't?
One other thought we had is whether it is possible that the Reconcile call completes before the database cleans up the lock in high CPU use cases. I wouldn't think so, but who knows?
Thanks,
Jeff
