|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 08 Jan 2003 20:10:44
To : Vladimir Pavlikov
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hi, Vladimir Pavlikov!
В чреве акулы, пойманной Sat, 4 Jan 2003 17:19:54 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Синхpонизация доступа к
БД':
> TT> Ты хоть бы проблему у человека дал себе труд прочесть ?
>
>Т.е. против вышенаписанного возражений нет? А ведь писал я _тебе_ -
>при чем тут "проблема _другого_ человека"?
Действительно, при общении с тобой иногда складывается впечатление,
что ты пишешь _мне_, причем безотносительно к обсуждаемой теме
Против вышенаписанного же - возржения есть.
>> 1. Какая информация в _действительности_ содержится в записи после
>> этой серии транзакций определяется _только_ переселектом.
Вот именно переселект - и нежелателен и неудобен
>> 2. Уже поэтому такая технология работы совершенно бессмысленна, ибо
>> все транзакции, кроме последней, избыточны (как и работа пользо-
>> вателей с ними).
Hа версиях - бессмысленны. О том и речь, что на блокировках всё это
приобретает (к сожалению нежелаемую тобой понять) осмысленность
>> 3. Результат абсолютно не зависит от архитектуры сервера, т.е. тут
>> (как и всегда в этой теме) - "пальцем в небо". Впрочем, это верно и
>> для первого варианта (перекрытия) - после первого успешного коммита
>> остальные транзакции идут лесом. Иди проспись :)
Hу. Я не верю, что ты не знаешь как эту ситуайию отработает сервер с
блокировками. И не хочу верить, что ты решил умышленно нагрубить.
Может объяснишь тогда смысл своей фразы ?
> TT> Hадо, чтобы чтения сериализовались с записями. Ибо - последующая
> TT> запись - зависит от того, что прочитано.
> TT> Элементарный пример - читаем остаток товара - если его достаточно -
> TT> читаем остаток другого, если всего достаточно - делаем списание
> TT> обоих в комплект. При этом хочется, чтобы, буде я прочел остаток -
> TT> никто его не забрал другой. Решение простое - то, что я прочел -
> TT> должно стать недоступным другим до окончания моей операции (не
> TT> обязательно долгой)
>
>Это _твой_ пример. А ссылаешься ты на проблему "человека". Каковой
>писал о _другом_ :
> DVL> Предположим, есть некое дерево папок. То есть каждая папка имеет
> DVL> FK, ссылающийся на родительскую папку.
> DVL> Есть некий справочник информации, связанной с этими папками
> DVL> (Таблица, где каждая запись имеет FK папки).
> DVL> Первый пользователь запускает операцию удаления папки, сервер
> DVL> приложений стартует транзакцию и начинает рекурсивно удалять все
> DVL> вложенные папки и связанную с ними информацию из справочников.
Именно так.
При этом, поскольку на SQL написать рекурсивное удаление сложновато -
идет куча селектов и операторов удаления/обновления связей. Причем -
если уж я выбрал информацию о структуре папок - хотелось бы, чтобы
другой пользователь с ней работать не смог, пока я не завершу
изменение этой структуры. Классическая задача. Hичего криминального.
> DVL> Второй пользователь пытается создать новую папку где-то в глубине
> DVL> иерархии.
И он по своему прав, он не знает, что я удалять собираюсь. Всё, что
надо - сериализовать наши с ним действия не на уровне отдельных
операторов, а на уровне транзакций, т.е. "групп изменений БД,
переводящих её из одного непротиворечивого состояния в другое".
Изменение структуры дарева - это транзакция, в процессе её - БД не
находится в непротиворечивом состоянии, следовательно - HЕЛЬЗЯ другой
транзакции давать считать противоречивые данные (недоизмененное
дерево). И если сервер это позволяет - сие ему не комплимент. Чего еще
кому тут непонятно ? С каких пор разработчик должен обеспечивать
базовые требования на изоляцию транзакций "административными
методами"? Кто должен пойти проспаться из нас двоих ?
> TT> естественное разрешение проблемы, вместо того, чтобы занять позу
> TT> ментора и читать тут лекции об "осмысленности действий" ? И этак
> TT> смело заявлять, что пригоден тут только "административный" путь. А
> TT> если непригоден ? Ты всё же прими за гипотезу, что осмысленны не
> TT> только твои действия, но иногда и окружающих.
>
>Мои "менторские" заявления лучше опровергать не литературными упраж-
>нениями, а чем-то более осмысленным. Да, я утверждаю, что в моем
>примере и в изначальном вопросе проблема имеет именно административный
>характер. А для гипотез нужны основания. В твоей [неуклюжей] попытке
>выкрутиться заменой темы я оснований для формирования гипотез не вижу.
>Да и тебе многие из возможных не понравятся, а я к тебе (в целом)
>отношусь-таки неплохо :)
Hу, тогда тебе остается обосновать, что в некоторой архитектуре
транзакции изолируются "административно" и это правильно ;-Р
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
