|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Oleg Bokanov 2:5020/400 25 Dec 2002 12:13:22
To : Dmitry V. Liseev
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hу ты бы хоть попробовал вначале, то о чем пишешь :(
В тот момент, когда первый пользователь начнет транзакцию удаляющую папку,
будет установлена блокировка.
Когда второй пользователь попытается вставить новую папку, дочернюю к
удаляемой будет осуществлена попытка блокировки родительской записи, которая
уже заблокирована первым пользователем. В результате, транзакция второго
пользователя будет ждать завершения транзакции удаляющей записи. Когда же
эта транзакция завершится, то вторая не сможет выполнить вставку, так как не
найдет родительскую запись, о чем и отрапортует тебе.
"Dmitry V. Liseev" <dimik@infopro.spb.su> сообщил/сообщила в новостях
следующее: news:auaesu$1bom$3@news.peterlink.ru...
> Dmitri Zakharov <Dmitri.Zakharov@p53.f5.n5004.z2.fidonet.org> wrote in
> message news:1040724356@p53.f5.n5004.z2.ftn...
>
> Hi!
>
> > Поставь interbase 6 - дело одной минуты.
> > Создай базу данных с одной таблицей.
> > запусти 2 копии isql.
> > в одной меняй данные. (1)
> > В дpугой делай выбоpки. (2)
> > (Так вот в этом окне (2) не увидишь никаких изменений пока не выдашь
> > commit или rollback)
> > Дефолтный уpовень там - snapshot.
>
> С этим я поигрался. Проблема в том, что обычно
> для выполнения некой функции сервер приложений
> делает несколько запросов к серверу БД, из которых
> часто сначала идет несколько SELECT'ов, на основе
> прочитанных данных принимается решение, затем
> идет несколько INSERT/UPDATE/DELET'ов. Это все
> в одной транзакции происходит. В течение
> этого процесса кто-то второй делает короткую
> операцию над некими данными и делает commit.
> Сервер БД в этот момент еще не знает, что первая
> транзакция также собирается потом читать эти-же
> данные. Соответственно он говорит второму, что его
> транзакция успешно закоммичена. Когда СУБД выяснит,
> что первая транзакция собирается читать эти-же данные,
> ее продолжение станет бессмысленным, т.к. snapshot,
> сделанный на момент начала первой транзакции уже
> устарел и первая транзакция рискует принять решение
> на основе устаревших данных. Жить становится интереснее,
> когда данные не просто меняются, а появляются или
> удаляются
>
> Предположим, есть некое дерево папок. То есть каждая
> папка имеет FK, ссылающийся на родительскую папку.
> Есть некий справочник информации, связанной с этими
> папками (Таблица, где каждая запись имеет FK папки).
> Первый пользователь запускает операцию удаления
> папки, сервер приложений стартует транзакцию и начинает
> рекурсивно удалять все вложенные папки и связанную
> с ними информацию из справочников. Второй пользователь
> пытается создать новую папку где-то в глубине иерархии.
> Сервер приложений стартует для него транзакцию, добавляет
> папку (ссылочная целостность не нарушается, т.к. родительская
> папка для нее еще не удалена и СУБД еще не знает, что скоро
> она будет удалена в первой транзакции, т.е. пересечение по
> данным еще не возникло и нет оснований в отклонении
> этой операции), и связанную с ней информацию в справочник.
> Эта операция завершается успешно и коммитится.
> После этого первая транзакция наконец-то добирается до
> попытки удалить соответствующую родительскую папку,
> в соответствии с идеологией snapshot и изоляции транзакций
> она не может удалить вновь появившуюся дочернюю папку,
> ибо не знает о ней и связанной с ней информации в справочнике,
> т.к. на момент начала первой транзакции ее еще не было.
> Hе удалять ее тоже нельзя, ибо при удалении родительской
> папки возникнет нарушение ссылочной целостности. Единственный
> выход - откатить первую транзакцию. То есть при выполнении
> операции типа DELETE FROM Folder WHERE ParentFolder=544
> должна каким-то образом возникнуть ошибка, чтобы сервер
> приложений откатил всю транзакцию. Если операция завершиться
> успешно, то либо вновь добавленная папка не будет удалена
> с вытекающим нарушением целостности, либо она будет
> обнаружена и удалена, но это будет означать, что в момент
> проведения транзакции было учтено вовсе не то состояние
> таблицы, которое было на момент ее начала.
>
> В таком случае получается, что этот snapshot должен помнить
> не только какие данные были на момент начала транзакции,
> но и каких данных еще небыло. Он что, полную копию всей
> БД для каждой транзакции создает? А если внутри транзакции
> не просто записи добавляются, а создаются или удаляются
> целые таблицы, триггера или констрейны?
>
> Следуя подобной логике получается, что большое количество
> коротких транзакций должны сделать ничтожно малой вероятность
> успешного прохождения хоть и редких, но длинных транзакций.
>
> Единственный выход - иметь некий способ руками указать
> блокируемые данные еще в самом начале транзакции
> до фактического к ним обращения, чтобы еще в начале
> длинной операции сервер точно знал, какие данные
> потребуются в ее ходе, тогда короткие транзакции, которые
> заявят блокировку этих-же данных, будут приостановлены.
> ____________________________
> С уважением, Лисеев Дмитрий.
> http://private.peterlink.ru/dimik/
> PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73
>
>
--- ifmail v.2.15dev5
* Origin: WEBPlus Ltd. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
