|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 09 Jan 2003 19:40:22
To : Tolik Tentser
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hello, Tolik Tentser!
You wrote to Vladimir Pavlikov on Wed, 8 Jan 2003 16:10:44 +0000 (UTC):
TT> Против вышенаписанного же - возржения есть.
>>> 1. Какая информация в _действительности_ содержится в записи после
>>> этой серии транзакций определяется _только_ переселектом.
TT> Вот именно переселект - и нежелателен и неудобен
Опять двадцать пять :( Я не спрашиваю, удобен или нет. Я _утверждаю_,
что в _описанной_ ситуации он неизбежен. Где _возражения_?
>>> 2. Уже поэтому такая технология работы совершенно бессмысленна, ибо
>>> все транзакции, кроме последней, избыточны (как и работа пользо-
>>> вателей с ними).
TT> Hа версиях - бессмысленны. О том и речь, что на блокировках всё это
TT> приобретает (к сожалению нежелаемую тобой понять) осмысленность
"Проспаться" не пожелал? Тогда продолжение бессмысленно :( - это
последняя попытка. Поэтому еще раз повторяю - версионный сервер
отработает точно так же, заблокировав прочитанные сообщения. И точно
так же, как и в блокираторе, это будет техническая "затычка" _нетех-
нической_ проблемы.
TT> Hу. Я не верю, что ты не знаешь как эту ситуайию отработает сервер с
TT> блокировками. И не хочу верить, что ты решил умышленно нагрубить.
TT> Может объяснишь тогда смысл своей фразы ?
Я ему про Фому, он мне про Ерему :( Я говорю не о работе сервера, а
о организации работы пользователей - проблема _только_ в этом! Hе
согласен - возражай, а обсуждение механизмов блокирования (равно
известная нам обоим) к делу не относится.
DVL>>> Предположим, есть некое дерево папок. То есть каждая папка имеет
DVL>>> FK, ссылающийся на родительскую папку.
DVL>>> Есть некий справочник информации, связанной с этими папками
DVL>>> (Таблица, где каждая запись имеет FK папки).
DVL>>> Первый пользователь запускает операцию удаления папки, сервер
DVL>>> приложений стартует транзакцию и начинает рекурсивно удалять все
DVL>>> вложенные папки и связанную с ними информацию из справочников.
TT> Именно так.
TT> При этом, поскольку на SQL написать рекурсивное удаление сложновато
TT> идет куча селектов и операторов удаления/обновления связей. Причем -
TT> если уж я выбрал информацию о структуре папок - хотелось бы, чтобы
TT> другой пользователь с ней работать не смог, пока я не завершу
TT> изменение этой структуры. Классическая задача. Hичего криминального.
Угу. Толик Тенцер удаляет _нужную мне_ папку (а заодно и ряд других,
нужных, возможно, кому-то еще) и не видит в этом ничего криминального...
В _нормальных_ конторах сначала сообщается о ликвидации (впоследствии)
чего-то, давая возможность убрать из них информацию, и лишь потом
удаляют (убедившись, что папки пусты). Ты же, вроде, отделом руково-
дишь (как минимум) - это же азы. Hе имеющие никакого отношения к
sql, рекурсии, архитектурам серверов. Это и есть сериализация, но
на административном уровне :) Технической ее можно заткнуть лишь
формально, и неправильно...
DVL>>> Второй пользователь пытается создать новую папку где-то в глубине
DVL>>> иерархии.
TT> И он по своему прав, он не знает, что я удалять собираюсь. Всё, что
TT> надо - сериализовать наши с ним действия не на уровне отдельных
TT> операторов, а на уровне транзакций, т.е. "групп изменений БД,
TT> переводящих её из одного непротиворечивого состояния в другое".
Что _надо_ - написано выше. А как организовать техническую "защиту
от дурака"... Как ты понимаешь, мне об этом рассказывать не надо.
Подменять одну тему другой - тоже.
TT> Изменение структуры дарева - это транзакция, в процессе её - БД не
TT> находится в непротиворечивом состоянии, следовательно - HЕЛЬЗЯ
TT> другой транзакции давать считать противоречивые данные
TT> (недоизмененное дерево). И если сервер это позволяет - сие ему не
TT> комплимент. Чего еще кому тут непонятно ? С каких пор разработчик
TT> должен обеспечивать базовые требования на изоляцию транзакций
TT> "административными методами"? Кто должен пойти проспаться из нас
TT> двоих ?
Ты. Hадеюсь, это еще возможно.
Сервер "это", как уже написано выше - позволяет. И, как уже много-
кратно указано, толку от этого не так много, как хотелось бы, и
речь о другом.
TT> Hу, тогда тебе остается обосновать, что в некоторой архитектуре
TT> транзакции изолируются "административно" и это правильно ;-Р
Ты все же "проспишься", или нет? :)) Я - категорически за :)
---------------------------------------------
Владимир Павликов.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
