|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 09 Jan 2003 20:32:32
To : Vladimir Pavlikov
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hi, Vladimir Pavlikov!
В чреве акулы, пойманной Thu, 9 Jan 2003 15:40:22 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Синхpонизация доступа к
БД':
> TT> Вот именно переселект - и нежелателен и неудобен
>
>Опять двадцать пять :( Я не спрашиваю, удобен или нет. Я _утверждаю_,
>что в _описанной_ ситуации он неизбежен. Где _возражения_?
Он более чем "избежен". если у удаляющей транзакции есть возможность
исключить доступ (в том числе и чтение) к удаляемым данным. Hа время
изменения. И никакого переселекта не понадобится, другие транзакции
получат новое состояние папок.
> TT> Hа версиях - бессмысленны. О том и речь, что на блокировках всё это
> TT> приобретает (к сожалению нежелаемую тобой понять) осмысленность
>
>"Проспаться" не пожелал? Тогда продолжение бессмысленно :( - это
>последняя попытка. Поэтому еще раз повторяю - версионный сервер
>отработает точно так же, заблокировав прочитанные сообщения. И точно
>так же, как и в блокираторе, это будет техническая "затычка" _нетех-
>нической_ проблемы.
Изоляция транзакций - нетехническая проблема ?
С каких пор ?
Ты поймешь всё же, что чтение дерева другой транзакцией "во время
изменения" - есть чтение несогласованных данных и прямое нарушение
изоляции ?
> TT> При этом, поскольку на SQL написать рекурсивное удаление сложновато
> TT> идет куча селектов и операторов удаления/обновления связей. Причем -
> TT> если уж я выбрал информацию о структуре папок - хотелось бы, чтобы
> TT> другой пользователь с ней работать не смог, пока я не завершу
> TT> изменение этой структуры. Классическая задача. Hичего криминального.
>
>Угу. Толик Тенцер удаляет _нужную мне_ папку (а заодно и ряд других,
>нужных, возможно, кому-то еще) и не видит в этом ничего криминального...
:-/
Мда ...
Сейчас договоримся, что удаление или изменение любых данных в БД
"нужных, возможно, кому-то еще" - есть криминальная операция и БД её
без административного регламента поддерживать не обязана.
>В _нормальных_ конторах сначала сообщается о ликвидации (впоследствии)
>чего-то, давая возможность убрать из них информацию, и лишь потом
>удаляют (убедившись, что папки пусты).
=8-()
Ой. Вот так, всегда, не уточнив, что там за папки (в исходном
сообщении я не помню такого что-то, что удаление требует
административного регламента, ибо В.П. так сказал, что так всегда
должно быть), вводим в теорию работы с БД новое понятие - удаление
любой структуры данных, эмулирующей папки при других работающих
пользователях недопустимо.
Да хоть и требует регламента, что я - за удалением всякой папки БД в
single user переводить должен ? Хана всему бизнесу, БД не умеет папки
удалять, а разработчики не велели иначе, 200 пользователей -
отключиться немедленно, клиенты подождут, я щас папки удалять буду.
Смешно ? Мне нет.
>Ты же, вроде, отделом руково-
>дишь (как минимум) - это же азы.
Ага. Азы см. выше. И ниже - СУБД обязана воспрепятствовать чтению
несогласованных данных другими транзакциями. Это даже не азы, это
базис для азов. Если она этого делать не умеет - то разговоры
разработчиков о "административном регламенте" - есть признак их
несостоятельности в качестве разработчиков.
>Hе имеющие никакого отношения к
>sql, рекурсии, архитектурам серверов. Это и есть сериализация, но
>на административном уровне :) Технической ее можно заткнуть лишь
>формально, и неправильно...
Ты знаешь я наверно так и не пойму что такое "административная
сериализация". Для меня это режим single user и, следовательно, бред.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
