与多个表进行交易时出现死锁

Question

My scenario is common: I have a stored procedure that need to update multiple tables. if one of updates failed - all the updates should be rolled back. the strait forward answer is to include all the updates in one transaction and just roll that back. however, in system like ours , this will cause concurrency issues. when we break the updates into multiple short transactions - we get throughput of ~30 concurrent executions per second before and deadlocking issues start to emerge. if we put it to one transaction which span all of them - we get concurrent ~2 per second before deadlock shows up.

in our case, we place a try-catch block after every short transaction, and manually DELETE/Update back the changes from the previous ones. so essentially we mimic the transaction behavior in a very expensive way... It is working alright since its well written and dont get many "rollbacks"... one thing this approach cannot resolve at all is a case of command timeout from the web server / client.

I have read extensively in many forms and blogs and scanned through the MSDN and cannot find a good solution. many have presented the problem but I am yet to see a good solution.

The question is this: is there ANY solution to this issue that will allow a stable rollback of update to multiple tables, without require to establish exclusivity lock on all of the rows for the entire duration of the long transaction.

Assume that it is not an optimization issue. The tables are almost at the max optimization probably, and can give a very high throughput as long as deadlock don't hit it. there are no table locks/page locks etc. all row locks on updates - but when you have so many concurrent sessions some of them need to update the same row...

it can be via SQL, client side C#, server side C# (extend the SQL server?). Is there such solution in any book/blog that i have not found?

we are using SQL server 2008 R2, with .NET client/web server connecting to it. Code example:

Create procedure sptest Begin transaction Update table1 Update table2 Commit transaction

In this case, if sptest is run twice, the second instance cannot update table 1 until instance 1 has committed. Compared to this

Create sptest2 Update table1 Update table2

Sptest2 has a much higher throughput - but it has chance to corrupt the data. This is what we are trying to solve. Is there even a theoretical solution to this?

Thanks, JS

Answer 1

I would say that you should dig deeper to find out the reason why deadlock occurs. Possibly you should change the order of updates to avoid them. Maybe some index is "guilty".

You cannot roolback changes if other transactions can change data. So you need to have update lock on them. But you can use snapshot isolation level to allow consistent reads before update commits.

Answer 2

For all inner joined tables that are mostly static or with a high degree of probability not effect the query by using dirty data then you can apply:

INNER JOIN LookupTable (with NOLOCK) lut on lut.ID=SomeOtherTableID

This will tell the query that I do not care about updates made to SomeOtherTable

This can reduce your issue in most cases. For more difficult deadlocks I have implemented a deadlock graph that is generated and emailed when a deadlock occurs contains all the detailed info for the deadlock.