Iz ovoga je očigledno da neka transakcija pokušava da preuzme kontrolu nad nekim resursom koji je već zaključan od strane druge transakcije. To što se transakcije ne izvršavaju nad istim redovima u tabeli nije od presudnog značaja jer verovatno to nije jedina tabela u bazi i verovatno je povezana sa nekim drugim tabelama, a to može da utiče na mnogo stvari.
Sem toga u MS SQL Serveru posoje mnoge opcije za podešavanje načina kako sistem kontroliše konkurentno izvršavanje, da citiram:
"Microsoft SQL Server 2005 supports a range of concurrency control. Users specify the type of concurrency control by selecting transaction isolation levels for connections or concurrency options on cursors. These attributes can be defined using Transact-SQL statements, or through the properties and attributes of database application programming interfaces .... "
Ja do sad nisam baš imao nekih problema sa time obzirom da obe baze koje sad koristim imaju vrlo malo upisa u odnosu na čitanje podataka tako da je "dead lock" situacija praktično skoro nemoguća, mada sam u testiranju uspeo da izazovem par zaključavanja pod uslovima koji se u praksi ne dešavaju, pa mi ni iskustva sa ovim nisu baš sveža.
U svakom slučaju preporučujem da pregledaš podešavanja izolacionih nivoa i konkurentnosti kurzora, a za nalaženje uzroka "dead locka" možeš da upotrebiš "SQL Server Profiler" i pregledaš logove grešaka.
iako se ovakvi problemi ne mogu potpuno eliminišu postoji skup pravila u radu koji verovatnoću za pojavu deadlokova smanjuje na najmanju meru, pa samim tim povećava i efikasnost funcionisanja celog sistema ali to je već preobimna tema za jedan odgovor na pitanje na koje ionako nije moguće dati kompletan odgovor.

Otprilike sam i ja naisao na slicna odgovore na stranim sajtovima. Ono sto mi je kod svega najcudnije je da aplikacija bez takvih problema radi pod Oracle, PostgreSQL kao i MySQL sa InnoDB, dakle SQL server definitivno radi neke stvari na samo njemu specifican zahtev. Cak i da se problem resi tako sto ce se podesavati nivo izolacije transakcija nigde se ne garantuje da to takvih problema nece doci, a ovo moze biti jako problematicno u koliko se na aplikaciji ocekuje velik broj konkurentnih zahteva.

Mozes biti ubedjen da samo SQL Server ima tih problema. Hej, poredis ga sa nekim RDBMS-ovima koji ne mogu ni da urade live backup. Da je to tako kao sto pricas onda bi deadlock pojam bio striktno vezan za SQL server i za nikog vise. Pogledaj ovaj link. Jedini nacin da se izbegne deadlock bi bio da sve ide na exclusive lock, ili da svaku transakciju na SQL serveru izvrsavas preko TRANSACTION ISOLATION LEVEL SERIALIZABLE ali naravno, ovo tesko da je izvodljivo, jer bi dobio samo niz seriajlizovanih operacija, sto ima da ukopa server u visoko konkurentnom okruzenju. Naravno, za ovo je najbolji heuristicki metod resavanja :)

poredim ga sa RDMBS-ovima pod kojima aplikacija treba da radi. :( Nema mi smisla da se tako nesto nikad ne desi pod Oracle (i to jos 10g express), dok je takvu situaciju prilicno lako izazvati kod Microsofta.

Microsoft? To je neki novi RDBMS?

Pa dao sam ti link za Oracle gde se vidi kako je i tamo moguc deadlock. Cak i pise 'best practice' koji je najsigurniji nacin da se izbegne deadlock koji je, da ne verujes, isti kao i za MS SQL a verovatno i za sve ostale baze. Vidi, necu ja ovde da svodim pricu SQL Server vs Oracle, (mada vesto si se dohvatio proroka, situacija sa svim drugim RDBMS-ovima nije tako svetla kao sa oracle-om - ne mislim samo na deadlock-ove) nego na to da deadlock-ovi svuda postoje ukoliko hoces da dozvolis shared lock-ove, kako god se zovu na drugim RDBMS-ovima.