我可以使用C＃锁来防止Web应用程序中的SQL Server死锁吗？

Question

I am writing a web application in Visual Studio 2010 using C#. The web app executes complex SQL Server 2008 statements that sometimes result in a deadlock if the same .aspx page is called more than once at the same time. The proposed solution is to use SQL server means to prevent these deadlocks, but my issue is that I don't really understand it well, which is not true about C#, that I know way better.

So I'm wondering, what is the downside of me using locks in the ASP.NET page (or locks in C#, or Windows named mutex) instead of doing the locking through SQL server to prevent these deadlocks?

PS. The SQL Server database in question is used only by this web application.

EDIT: The following is C# code that executes SQL statements:

int iNumRows = 0;

using (SqlConnection cn = new SqlConnection(strConnection))
{
    cn.Open();

    using (SqlCommand cmd = new SqlCommand(strSQL, cn))
    {
        //Use C# lock here
        iNumRows = Convert.ToInt32(cmd.ExecuteScalar());
        //Release C# lock here
    }
}

And here's a sample of SQL (that in reality is dynamically composed by C# script):

SET XACT_ABORT ON;
BEGIN TRANSACTION;

DELETE FROM [dbo].[t_Log_2] 
      WHERE [idtm]<'2011-03-12 08:41:57';

WITH ctx AS(
     SELECT MIN([idtm]) AS mdIn, 
            MAX([odtm]) AS mdOut 
           FROM [dbo].[t_Log_2] 
          WHERE [type] = 0 
            AND [state] = 0 
            AND [huid] = N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4' 
            AND [odtm] >= '2013-03-11 06:33:32' 
            AND [idtm] <= '2013-03-11 06:43:12' 
           ) 
INSERT INTO [dbo].[t_Log_2] 
([oid],[idtm],[odtm],[type],[state],[huid],
 [cnm],[cmdl],[batt],[dvtp0],[dvtp1]) 
SELECT 
    2, 
    CASE WHEN mdIn IS NOT NULL 
          AND mdIn < '2013-03-11 06:33:32' 
         THEN mdIn 
         ELSE '2013-03-11 06:33:32' 
         END,
    CASE WHEN mdOut IS NOT NULL 
          AND mdOut > '2013-03-11 06:43:12' 
         THEN mdOut 
         ELSE '2013-03-11 06:43:12' 
         END,
    0,
    0,
    N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4',
    null,
    null,
    0,
    1,
    null 
FROM ctx 

SELECT ROWCOUNT_BIG()

DELETE FROM [dbo].[t_Log_2] 
      WHERE [type] = 0 
        AND [state] = 0 
        AND [huid] = N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4' 
        AND [odtm] >= '2013-03-11 06:33:32' 
        AND [idtm] <= '2013-03-11 06:43:12' 
        AND [id] <> SCOPE_IDENTITY()

DELETE FROM [dbo].[t_Log_2] 
      WHERE [type] = 0 
        AND [huid] = N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4' 
        AND [idtm] >= (SELECT [idtm] FROM [dbo].[t_Log_2] 
                                    WHERE [id] = SCOPE_IDENTITY()) 
        AND [odtm] <= (SELECT [odtm] FROM [dbo].[t_Log_2] 
                                    WHERE [id] = SCOPE_IDENTITY()) 
        AND [id] <> SCOPE_IDENTITY() 

;WITH ctx1 AS( 
     SELECT [idtm] AS dI 
       FROM [dbo].[t_Log_2] 
      WHERE [id] = SCOPE_IDENTITY() 
             )
UPDATE [dbo].[t_Log_2] 
        SET [odtm] = ctx1.dI 
       FROM ctx1 
      WHERE [id] <> SCOPE_IDENTITY() 
        AND [type] = 0 
        AND [huid] = N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4' 
        AND [idtm] < ctx1.dI 
        AND [odtm] > ctx1.dI 

;WITH ctx2 AS(
     SELECT [odtm] AS dO 
       FROM [dbo].[t_Log_2] 
      WHERE [id] = SCOPE_IDENTITY() 
             ) 
UPDATE [dbo].[t_Log_2] 
        SET [idtm] = ctx2.dO 
       FROM ctx2 
      WHERE [id] <> SCOPE_IDENTITY() 
        AND [type] = 0 
        AND [huid] = N'18ef4d56-6ef3-906a-a711-88d1bd6ab2d4' 
        AND [idtm] < ctx2.dO 
        AND [odtm] > ctx2.dO 

COMMIT TRANSACTION;
SET XACT_ABORT OFF

Answer 1

what is the downside of me using locks in the ASP.NET page (or locks in C#, or Windows named mutex) instead of doing the locking through SQL server to prevent these deadlocks?

Instead of causing deadlocks you will cause livelocks.

A deadlock occurs when the wait graph contains a cycle (A wait on B, B waits on A). SQL Server periodically inspects all the wait graphs and looks for cycles. When one such cycle is detected the cycle is broken by choosing a victim and aborting it's transaction.

If you move some of these locks outside of the SQL Server controlled realm, ie. in process mutexes, critical sections, C# events or whatever, the wait graphs cycles will still occur but now the cycle will complete through the app, thus it will be undetectable by SQL Server (A waits for B in SQL, but B waits for A in the app). Since the deadlock monitor will not see a cycle, it will not run the deadlock resolving algorithm (choose a victim, abort it's transaction) and the deadlock will stay on forever. Congratulations, now your application simply hangs instead of raising a deadlock exception!

You don't have to take my word from it, other more experienced have already been burned by this issue and learned the hard way, but fortunately wrote about it so you can learn the easy way. This very site you're reading is an example .

Solving deadlocks in SQL Server is fairly easy once you understand the issue. If you capture and attach the deadlock graph (the XML, not the picture!), along with the exact definition of your tables, perhaps we can help. Alas, you already ignored such request so I guess the only question to ask is Would you like more rope?

Answer 2

Without knowing enough detail, could not find where it really cause deadlock, I can guess it probably because of key range caused the deadlock, which means deadlock happened on the index of table t_log_2, since you have the delete and update, definitely they are not happening on same row, but they can happen on same key range, or one process can hold A range, request B range, and another process can hold B range and request A range. You can use SQL Profiler to trace the deadlock and see where it exactly happened. Or, simply, if it doesn't hurt your performance too much, you can set transaction isolation level to [repeatable read] or even [serializable].

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
....
BEGIN TRANSACTION
....