 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Sergey Prach 2:5020/400 28 Dec 2002 00:12:49 To : Dmitry Novikov Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hi! "Dmitry Novikov" <dim@rnivc.kis.ru> сообщил/сообщила в новостях следующее: news:auhkuh$2665$1@ddt.demos.su... > > > В блокировачнике одна из транзакций не сдыхает, а ждет, и только в > > > редких случаях (dead lock) сдыхает, но опять же одна, выбранная > жертвой, > > > а не обе. > > > > Hу и какая же при dead lock-е выживает? По каким критериям > происходит > > отбор? > Typically, SQL Server chooses the thread running the transaction that is > least expensive to undo as the deadlock victim. Alternatively, a user > can set the DEADLOCK_PRIORITY of a session to LOW, using the SET > statement. The DEADLOCK_PRIORITY option controls how sessions are > weighed in deadlock situations. If a session's setting is set to LOW, > that session becomes the preferred victim when involved in a deadlock > situation Скажу честно, что я счтал, что при dead lock погибают обе трназкции, но логически я понимал, что даже с теретичской точки зрения достаточо гибели одной, а уж с практичекой и подавно. А в доку глянуть за всем этим новогодним дурдомом - половина клиентов накупило себе домой компьюетры и почему-то считают, что я всю жизнь мечтал ублажить их чадо в области настройки компьютера. Посему в доке искать подтвежения/опровержения времени не хватило. -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: LtawaSoft (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/1678692a7b1ff.html, оценка из 5, голосов 10
|
|
|