 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 23 Dec 2002 22:32:36 To : Dmitry V. Liseev Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hello, Dmitry V. Liseev! You wrote to on Mon, 23 Dec 2002 17:20:17 +0000 (UTC): DVL> Собственно, возникли вопросики. Вот, есть в учебниках такая задача, DVL> как перевод денег с одного счета на другой. Типа, запускаем DVL> транзакцию, снимаем с одного счета, кладем на другой, затем DVL> коммитим или откатываем. DVL> Вроде, все надежно, как в танке и целостность гарантирована. Теперь DVL> допустим, что несколько желающих попытались провести несколько DVL> подобных транзакций над пересекающимся множеством счетов. Лучше одну (банковскую) операцию делать отдельной транзакцией. Время выполнения близко к нулю так же, как и вероятность конф- ликта с другой транзакцией. Если же не повезет - вторую можно и повторить. DVL> Транзакции обычно ассоциируются с модификацией данных. А как быть с DVL> чтением? Транзакции должны ассоциироваться с любыми действиями с данными :) DVL> Предположим, некто пытается построить отчет по данным, которые DVL> постоянно меняются. Тут тоже применимо понятие целостности. То DVL> есть, пока некто строит отчет, требуемые для него данные можно DVL> читать (для других аналогичных отчетов), но нельзя изменять. В DVL> противном случае отчет будет некорректным. Он не будет некорректным, если проводить его на требуемом (высоком) уровне изоляции. Правда, на блокирующем сервере возможен завис на блокировке с последующим откатом по таймауту. Если это начнет дос- тавать, то - либо "таймшер" (раздвиг по времени модификаций и отчетов) либо использование отдельного (синхронизируемого) сервера для отчетов. DVL> В приведенной модельной задаче просто не сведется баланс, то есть будет DVL> нарушена целостность данных, ибо получается, что баланс сводится после DVL> того, Целостность данных (в базе) нарушена не будет, будет неверен отчет. Этого можно гарантированно избежать при уровне изоляции "снапшот". DVL> Получается, что реализация сабжа полностью зависит от прикладной DVL> задачи и делается руками. Hафига тогда уровни изоляции транзакций и DVL> чем они могут помочь? Выше написано. А вот руками-то это сделать как раз нельзя. Разве что - административным разведением пользователей по времени до состояния singleuser :) DVL> Я нигде не видел сколь-нибудь глубокого обсуждения проблем DVL> многопользовательского доступа и сам не особо над этим задумывался DVL> раньше, считая, что все делает умный сервер. Делает, если умный программер указывает правильные уровни изоляции. Другое дело, что высокие уровни тяжелы, особенно для блокировщиков. Дальше - лишь методы, указанные в третьем "параграфе". Hу и предва- рительная оптимизация запросов с целью уменьшения продолжительности выполнения транзакций и незахватом ими данных сверх необходимого. --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488056dcdfe.html, оценка из 5, голосов 10
|
|
|