|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Practh 2:5020/400 06 Jun 2001 13:51:16
To : All
Subject : Hа: Informix ?
--------------------------------------------------------------------------------
Hi!
"Ilya Zvyagin" <ziv@fct.ru> сообщил/сообщила в новостях следующее:
news:991814202.985268@gatekeeper.fct.ru...
> >Так не бывает. А вот логическую вероятность дедлока в большинстве задач
> >действительно можно свести к нулю.
>
> Тебе не кажется, что ты сам себе противоречишь ?
> И что такое "логическую вероятность дедлока" ?
> Дедлок - он один. Это вполне определенная ошибка,
> которая может возникнуть при исполнении запроса.
> Вероятность (статистическая) его возникновения -
> это отношение кол-ва запросов с дэдлоком ко всему к-ву
> посланных запросов.
Илья, здесь я тоже с тобой не согласен. Я пользуюсь в этом плане в
основном практическими выкладками и ползуюсь следующей методой для избежания
"замка": просто перед началом любой транзакции, котороая может приводить к
такой ситуации, заблокировать все необходимые ресурсы одним запросом, а в
большинстве случаев это возможно. Т.е перед тем как начать перекрестное
обновление (из своего опыта это наиболее частые источника "замков"),
ставится запрос, корый просто тупо выбирает все записи, необходимые для
транзакции, с опцией updlock. Типа: SELECT @Dump=Fld FROM .... WHERE ... .
Стоимость такого запроса не высока, а от греха подальше он отводит.
Если какая-то из записей, в этот момент занята, то вся транзакция
становится в ожидание снятия блокировки. Аналогично и для паралельных
транзакций.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
