|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 26 Dec 2002 17:44:26
To : Dmitry V. Liseev
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hello, Dmitry V. Liseev!
You wrote to Dmitri Zakharov on Tue, 24 Dec 2002 20:11:40 +0000 (UTC):
DVL> С этим я поигрался. Проблема в том, что обычно для выполнения некой
DVL> функции сервер приложений делает несколько запросов к серверу БД,
DVL> из которых часто сначала идет несколько SELECT'ов, на основе
DVL> прочитанных данных принимается решение, затем идет несколько
DVL> INSERT/UPDATE/DELET'ов. Это все в одной транзакции происходит. В
DVL> течение этого процесса кто-то второй делает короткую операцию над
DVL> некими данными и делает commit.
DVL> Сервер БД в этот момент еще не знает, что первая транзакция также
DVL> собирается потом читать эти-же данные. Соответственно он говорит
DVL> второму, что его транзакция успешно закоммичена. Когда СУБД
DVL> выяснит, что первая транзакция собирается читать эти-же данные, ее
DVL> продолжение станет бессмысленным, т.к. snapshot, сделанный на
DVL> момент начала первой транзакции уже устарел и первая транзакция
DVL> рискует принять решение на основе устаревших данных. Жить
DVL> становится интереснее, когда данные не просто меняются, а
DVL> появляются или удаляются
snapshot все же наиболее подходит для длинный согласованных чтений.
Все модификации желательно делать максимально короткими транзакци-
ями, для подавляющего большинства которых достаточно уровня rc.
DVL> Предположим, есть некое дерево папок. То есть каждая папка имеет
DVL> FK, ссылающийся на родительскую папку.
DVL> Есть некий справочник информации, связанной с этими папками
DVL> (Таблица, где каждая запись имеет FK папки).
DVL> Первый пользователь запускает операцию удаления папки, сервер
DVL> приложений стартует транзакцию и начинает рекурсивно удалять все
DVL> вложенные папки и связанную с ними информацию из справочников.
DVL> Второй пользователь пытается создать новую папку где-то в глубине
DVL> иерархии.
Очень похоже на бессмыслицу, сорри. Я имею ввиду не у тебя, а у
пользователей. Трудно найти смысл в удалении папок, если другому
нужна одна из них в _то же самый момент_. Такие вещи могут (и должны)
решаться только на административном уровне, у пользователя. Ты же
максимум что можешь сделать - select for update. Тогда на данные,
подпадающие под условие запроса, будет наложена блокировка, и
второй пользоватеь получит "отлуп". Hо я вовсе не уверен, что
это хорошо - ведь будет удалена (первым) _нужная ему_ папка.
Поэтому - только административным путем, select for update - это
средство "послать" заказчика, ткнув его носом типа "у меня
проблем нет" :)
DVL> В таком случае получается, что этот snapshot должен помнить не
DVL> только какие данные были на момент начала транзакции, но и каких
DVL> данных еще небыло.
Тогда это не snapshot, а rc.
DVL> Он что, полную копию всей БД для каждой транзакции создает?
Можно сказать и так. Hе физически, конечно. Просто при любой
модификации остается еще и старая версия, и транзакции доступна
только она. Разумеется, она "видит" записи, удаленные после ее
старта, и не видит добавленных - речь действительно идет о
_мгновенном_ снимке базы.
DVL> А если внутри транзакции не просто записи добавляются, а
DVL> создаются или удаляются целые таблицы, триггера или констрейны?
Без разницы.
DVL> Следуя подобной логике получается, что большое количество коротких
DVL> транзакций должны сделать ничтожно малой вероятность успешного
DVL> прохождения хоть и редких, но длинных транзакций.
Hет. Если длинной транзакции не нужен снимок - она отработает по
данным "как есть". Если нужен - тогда snapshot "заморозит" базу.
А осмысленную работу при бессмысленном использовании обеспечить
невозможно, да и не нужно.
DVL> Единственный выход - иметь некий способ руками указать блокируемые
DVL> данные еще в самом начале транзакции до фактического к ним
DVL> обращения, чтобы еще в начале длинной операции сервер точно знал,
DVL> какие данные потребуются в ее ходе, тогда короткие транзакции,
DVL> которые заявят блокировку этих-же данных, будут приостановлены.
Как указано выше - select for update. Там же написано, что это
"затычечный" способ прикрытия собственной ж. Любая совместная
работа _д.б._ организована, иначе вреда от нее больше, чем пользы...
---------------------------------------------
Владимир Павликов.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
