![]() ![]() ![]() Which is why the application should be coded to handle that. A properly designed database on a improperly configured SQL Server can most definately deadlock unexpectedly. Those aren't database design problems, they are configuration problems. Intraquery parallelism deadlocks are also becoming more commonplace due to the reduction of cost for multi-core multi-processor hardware. Communication Buffer deadlocks can occur infrequently that you won't fix because the lock is not on a resource you can control or change. These days not all deadlocks are preventable. ![]() That is bad application side design coupled with potentially problemattic database design as well. The point being made is that the database transaction problem of a deadlock shouldn't break the application on the front end. It's not that every request has to be retried, or that they have to retry all the time. Even in the worst instance of deadlocking I have dealt with while consulting, and deadlocks were occuring roughly every 3-5 seconds, this was a very small portion of the overall workload that was actually being submitted. Nope, I said what I meant, and I meant what I said there.Ī properly designed application would have handling in place to deal with a deadlock occurence. Imagine, for example, if all client applications to any server they talk to had to retry their requests all the time - like, say, your web browser to any web server? What was rather meant, I hope, is that a properly designed database would never get you into unexpected deadlocks. can intercept the 1205 error and resubmit the deadlock victim request back to SQL Server" is forgetting a few basic things. The claim "that a deadlock in and of itself is not necessarily a problem" and suggestion that "A properly designed and coded application. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |