Re: Avoiding any locks in SQL Servers - read and understand....itsmagic.

Christopher Browne <cbbrowne_at_acm.org> wrote in message news:<bj0pvf$dnrld$1_at_ID-125932.news.uni-berlin.de>...
>
> If a deadlock is detected, I can't see any option particularly better
> than rolling the transaction back, and having the client try again
> later.

One transaction dropped is far better than "transactions dropped"? As in the tr that "clicked" the deadlock. Or some other algorithm. The problem I have is if all this "non-locking" on write takes place under the "serialization" of a supervisor, what happens when one of those serialised ones is the object of a deadlock? What exactly gets rolled back and in which sequence. Worries me as no matter what scenario I try, without locking there WILL be a loss of data.

>
> ATM machines /do/ do things like that, albeit normally as a result of
> hardware or network problems, as opposed to transaction deadlocks.

Not even that. All it needs is the right sequence of accesses to a given pair of accounts by two ATMs (or more generally any two given processes), if we're gonna allow multiple updates o the same row without locking. An on-line banking systems contains sufficiently large number of business functions that it may well be impossible to avoid the occasional deadlock. Hence the advantage of ensuring of their detection by the db software rather than having to code the darn thing in the app. Received on Wed Sep 03 2003 - 03:39:41 CDT