views:

41

answers:

1

I use linq-sql and this is what I need.

Sub Commit()
Try

StepStart:

Transaction Scope Serialized
Begin Transaction
Check BusinessRule1
Check BusinesRule2

if BusinessRulesFailed
{ Transaction.Rollback }
else {
Query = db.out
db.SubmitChanges()
Transaction.Commit()
}

Catch DeadLockException
Goto StepStart

End Try

End Sub

Is it ok to follow this approach? Can someone give me an example in C# or VB.Net

A: 

Yes, it's OK to use this approach. We do something similar. I'd a small delay though, say 500 ms.

With the SQL Server (and Sybase) locking strategy deadlocks will always happen: you can can only reduce the possibility as per MSDN (for 2000 bit still valid). Which also says to retry.

I've also seen commercial apps that retry too.

The other option is to enable snapshot isolation which is not perfect though

gbn
The problem is that it even happens for simple reads. Can't wrap retry's for all reads. That's not clean.
Dasiths
Reads should not deadlock usually. Are you sure it not some kind of transaction?
gbn
hmm reads do turn out to be deadlocks, in linq the default transaction isolation level is readcomitted and hence the problem.
Dasiths
readcomitted is the default all over. it is not the problem: trust me
gbn
please read http://omaralzabir.com/linq_to_sql_solve_transaction_deadlock_and_query_timeout_problem_using_uncommitted_reads/are you sure that reads should not give out deadlocks?
Dasiths
Thanks for the clarifiaction btw. I am not wrapping my reads inside transactions anywhere in the app. But the deadlock I got was on a read. A simple read like select p.x=2 and p.y > 10 and p.y <20
Dasiths
With LINQ I see setting the snapshot isolation as a viable option. Should I use READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION ?
Dasiths