|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Fedor 'Cruger' Tersin 2:5020/794.139 31 May 2001 23:43:23
To : ziv@fct.ru
Subject : Informix ?
--------------------------------------------------------------------------------
Ilya Zvyagin навис на All
>> А как? Изменение (собственно запись нового значения в буфер и отметка в
U> логе)
>> это практически атомарный процесс. Привязать блокировку к записи в лог?
U> Типа:
>> удалось заблокировать - пишем, нет - посылаем? Hо потом в самом деле, если
U> Так между прочим и делается. Ты это с иронией ? Тогда она не понятна.
Типа, я это и имел в виду, когда говорил "после".
>> будет вызыватся after триггер, он может захотеть еще что то поменять ->
>> еще что то придется блокировать. Вот он и источник дэтлоков.
U> Естественно придется. Куда же деваться ? А насчет источника - знаешь ли,
U> окромя триггеров дофига может быть других проблем , ведущих к deadlocks.
U> Короче, дэдлоков боятся - на сервере не работать.
Хм, вообще, дэтлок - признак плохого проектирования работы с БД. Разве я не
прав?
>> Если же сначала сделать в клиентском контексте слепок изменямых данных (в
U> том
>> числе и after триггерами), потом в монопольном режиме попытаться все
>> заблокировать и записать в лог, траблов не будет. Если же заблокировать не
>> удалось - подождать.
U> Такая схема работы не всегда приемлема. Она будет перезаписывать более
U> позние изменения.
Hет, ждать, если кто то читает. Если кто то пишет - подождать его коммита, и
либо послать, либо нет.
>> Hу а если блокируемые данные уже успел кто то поменять - послать. Если
>> слепок сделать не получается (требуемые данные в БД уже кем
U> Что то я не понял - ты за сервер это собираешся делть ? Он же только этим
U> и занимается.
Да нет, это я думаю, как по идее можно было бы организовать работу сервера, не
приводящую к детлокам в таких простых случаях, один из которых я описал.
U> Ты не понимаешь одного - deadlock-и неизбежны до тех пор, пока не будет в
U> БД ровно одного пользователя.
Простейшая схема их избежания - все пользователи в начале любой транзакции
блокируют один и тот же ресурс. Практически, если сервер будет работать
нормально, а работа с БД будет правильно спроектирована - детлоки вряд ли будут
встречаться.
Fedor.
--- WP/95 Rel 1.78E (215.0) Reg.
* Origin: cruger@galaktika.ru && ICQ#5167246 (2:5020/794.139)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Informix ? 
