|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry V. Liseev 2:5020/400 25 Dec 2002 00:11:40
To : Dmitri Zakharov
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
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: Peterlink ISP News System (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
