Answer by Jeff Moden
I had a similar situation with such a "sequence" table at my old job. The "GetNextID" proc similar to both of yours was causing an average of 640 deadlocks per day with daily spikes to more than 4,000....
View ArticleAnswer by Matt Whitfield
+1 for the question and +1 for grant - but have you considered using a slightly different method for logging? It's pretty unlikely that you are going to be logging many separate category and counter...
View ArticleAnswer by Kev Riley
Definitely agree with Grant's comments.I had a similar situation once with high-concurrency on a session data table, and after much trial and error with isolation levels, try/catch blocks etc. the...
View ArticleAnswer by Grant Fritchey
If anything, snapshot isolation might make this have more problems, not fewer, although you're unlikely to hit as many deadlocks. Absolutely you should implement TRY/CATCH for the deadlocks. You can...
View ArticleAnswer by Jeff Moden
I had a similar situation with such a "sequence" table at my old job. The "GetNextID" proc similar to both of yours was causing an average of 640 deadlocks per day with daily spikes to more than 4,000....
View ArticleAnswer by Matt Whitfield
+1 for the question and +1 for grant - but have you considered using a slightly different method for logging? It's pretty unlikely that you are going to be logging many separate category and counter...
View ArticleAnswer by Kev Riley
Definitely agree with Grant's comments.I had a similar situation once with high-concurrency on a session data table, and after much trial and error with isolation levels, try/catch blocks etc. the...
View ArticleAnswer by Grant Fritchey
If anything, snapshot isolation might make this have more problems, not fewer, although you're unlikely to hit as many deadlocks. Absolutely you should implement TRY/CATCH for the deadlocks. You can...
View Article
