|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 06 Jun 2001 11:58:32
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Vladimir Pavlikov wrote in message <9fieuv$re8$5@host.talk.ru>...
>> >Глупости. Взаимоблокировка возможна лишь при неверном проектировании/
>> "Hевозможен" = вероятность возникновения DEADLOCK-а = 0.
>Так не бывает. А вот логическую вероятность дедлока в большинстве задач
>действительно можно свести к нулю.
Тебе не кажется, что ты сам себе противоречишь ?
И что такое "логическую вероятность дедлока" ?
Дедлок - он один. Это вполне определенная ошибка,
которая может возникнуть при исполнении запроса.
Вероятность (статистическая) его возникновения -
это отношение кол-ва запросов с дэдлоком ко всему к-ву
посланных запросов.
>Выше же написано "для задачи/условий эксплуатации". Я не вижу ни того, ни
>другого - как будем "фиксировать сервер"? Разве что для самых крайних
Положим, существует некий гипотетический сервер, механизм разведения
транзакций которого нам не известен. Точно известно, что там могут
быть дэдлоки - они ведь могут быть.
Все.
>кую локальную копию" базы. В природе нет, но реализуемо.
Весело. :-)
>Если ты желаешь написать ( и опубликовать, и заработать :) монографию -
Hет. Я не этого добиваюсь.
>годится. Серьезно - ты во что оцениваешь объемы? Я не настолько заинтере-
>сован в твоем согласии :) Тут элементарщину находятся желающие не понять,
>а в данной теме....
Хочется одного - признать , что в многопользовательских системах
DEADLOCK - неизбежное явление, т.е. он может возникать всегда.
Можно и нужно снижать вероятность DEADLOCK, возможно до
очень маленькой величины, но абсолютно исключить его появление
HЕВОЗМОЖHО.
Собственно эту _элементарную_ мысль я и хочу донести до народа.
Ты с ней вроде бы согласился ?
Тогда к тебе лично вопросов у меня нет, я вобщем понял твою позицию
по данному вопросу и ее разделяю.
Вобщем и у меня и время , и желание дискутировать на эту тему иссякают.
Тем более, что вроде бы сошлись.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
