Having the same problem with a 10.2 geodb on SQL server... has there been any resolution or suggestion for this?
Thanks
Hi John,
I am also facing similar issue with SQL Server (ArcGIS SDE 10 SP3), can you kindly share your patch
Michael, we were never able to convince ESRI that it was a real problem. Our final solution was to patch [sde].[SDE_state_lock_def_insert] (and to cross our fingers!!). This has proved to be a great success on 10.0.
We are just about to start on 10.2 migration and so we will be reviewing situation to see if our patch is still required.
On a side note we have recently started to see occasional deadlocks in pinfo_tran and table_lock_del_tran (Still on 10.0). I have not yet had a chance to investigate
We have stumbled the same issue, thank you John for identifying the problem and sending us to the right direction.
As John mentioned the issue is with the [dbo.SDE_state_lock_def_insert] procedure.
we have investigated the issue deeply, and found that the deadlocks are happening when the [dbo.STATE_state_check_lock_conflicts] trying to convert the IX (Intent Exclusive) lock to X (Exclusive). on the [dbo.SDE_state_locks] table while opening a local cursor with a table hint.
The problem is that before [SDE_state_lock_def_insert] procedure runs, the [dbo.SDE_state_lock_def_insert] calls the
[dbo.SDE_state_lock_def_delete] (in the same transaction) that making cleanup in the [dbo.SDE_state_locks] table, via DELETE instruction. this in turn acquiring a IX lock on [dbo.SDE_state_locks] table, and then if it delete any row while running, it acquiring row X lock on the deleted row. this locks are held till the end of the outmost transaction.
so when the later procedure called, it is deadlocked, on this X locks, cause it tries to get X lock on whole table, and for that it need to lock wait till other sessions release the X locks on the rows, which in turn waiting on other to do the same.
The solution, that is worked for us:
setting a table hint inside the [dbo.SDE_state_lock_def_delete] procedure on both DELETE operations, that instruct to acquire a table exclusive lock on whole table, right away.
apply the hint after the FROM clause as follows: WITH (TABLOCKX, HOLDLOCK).
it worked like a charm, no deadlocks anymore .
still checking for performance penalty. but it worth it
hope ESRI will understand that it is a major issue and will fix that in the new releases.
This was resolved with the 10.2.1 database upgrade and was a confirmed but in 10.0 SP5.
Is it possible that Not applying something in a 10.0 pre 10.3 period would carry forward this behavior?
I'm currently supporting a Data collector app in a 10.3 Geodatabase. I did not do the upgrade but this is a long standing geodatabase. Currently under a heavy load ; 200 or so users it is deadlocking to the point that the application is unusable.