|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 05 Jun 2001 15:16:27
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Hello! "Ilya Zvyagin" <ziv@fct.ru> wrote:
> >Глупости. Взаимоблокировка возможна лишь при неверном проектировании/
> >использовании или при использовании хренового (для задачи/условий
> >эксплуатации) сервера.
> Т.е. перефразируя ( но не меняя сути высказывания )
> "При верном проектировании и использовании правильного сервера Deadlock
> HЕВОЗМОЖЕH".
> "Hевозможен" = вероятность возникновения DEADLOCK-а = 0.
Так не бывает. А вот логическую вероятность дедлока в большинстве задач
действительно можно свести к нулю.
> Следовательно, существуют методы проектирования и сервера, применяя
> которые можно абсолютно исключить возможность DEADLOCK-а.
> Предлагаю чтобы не возбуждать излишних споров, зафиксировать
> сервер - а то получится, что один (или несколько ) серверов
> хороший, а все остальные - плохие. Пусть будет один вполне конкретный
> сервер ( на самом деле вполне абстрактный ).
Выше же написано "для задачи/условий эксплуатации". Я не вижу ни того, ни
другого - как будем "фиксировать сервер"? Разве что для самых крайних
случаев :
1. Однопользовательская система в однозадачной среде на десктопе - что
угодно из-за идеальных условий эксплуатации.
2. Для [почти] любых условий и задач - _полно_версионник с единственным
уровнем изоляции (snapshot), предоставляющий каждой транзакции "логичес-
кую локальную копию" базы. В природе нет, но реализуемо.
> Мог бы ты сформулировать те самые правила, которых нужно придерживаться при
> проектировании БД и ПО, чтоб абсолютно исключить возможность DEADLOCK-ов.
Только правил недостаточно, но они необходимы. Многие неоднократно упо-
минались в эхах по разным поводам (размеры, уровни изоляции...) но главное -
они должны быть связаны с особенностями серверов, задачами и условиями
эксплуатации - прикажешь привести их full outer join? :)
> Если они будут применимы, т.е. не будут противоречить неким абстрактным
> ( в разумных пределах ) техническому заданию и требованию,
> то я с тобой соглашусь. Требования будем формулировать например исходя
> из элементарного здравого смысла.
Если ты желаешь написать ( и опубликовать, и заработать :) монографию -
годится. Серьезно - ты во что оцениваешь объемы? Я не настолько заинтере-
сован в твоем согласии :) Тут элементарщину находятся желающие не понять,
а в данной теме....
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
