 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Dmitry V. Liseev 2:5020/400 23 Dec 2002 21:20:17 To : All Subject : Синхронизация доступа к БД -------------------------------------------------------------------------------- Hi, All! Меня тут проблема сабж особо напрягать стала. Собственно, возникли вопросики. Вот, есть в учебниках такая задача, как перевод денег с одного счета на другой. Типа, запускаем транзакцию, снимаем с одного счета, кладем на другой, затем коммитим или откатываем. Вроде, все надежно, как в танке и целостность гарантирована. Теперь допустим, что несколько желающих попытались провести несколько подобных транзакций над пересекающимся множеством счетов. Вроде есть уровни изоляции транзакций. Есть сервера - версионники, есть - блокировочники. Либо нужно пытаться начать все требуемые транзакции одновременно, а затем откатить те из них, которые вызвали конфликт, стараясь мнимизировать потери впустую затраченных ресурсов, либо нужно блокировать требуемые данные, пытаясь провести конфликтующие транзакции последовательно. Сразу возник еще один вопрос. Транзакции обычно ассоциируются с модификацией данных. А как быть с чтением? Предположим, некто пытается построить отчет по данным, которые постоянно меняются. Тут тоже применимо понятие целостности. То есть, пока некто строит отчет, требуемые для него данные можно читать (для других аналогичных отчетов), но нельзя изменять. В противном случае отчет будет некорректным. В приведенной модельной задаче просто не сведется баланс, то есть будет нарушена целостность данных, ибо получается, что баланс сводится после того, как _все_ транзакции завершены (успешно или не успешно), но в момент их проведения он не сводится. Сразу вытекает еще один вопрос. Получается, что реализация сабжа полностью зависит от прикладной задачи и делается руками. Hафига тогда уровни изоляции транзакций и чем они могут помочь? Я нигде не видел сколь-нибудь глубокого обсуждения проблем многопользовательского доступа и сам не особо над этим задумывался раньше, считая, что все делает умный сервер. Может, кто-то этим серъезно занимался? Какие методики, литература, особенности реализации в разных серверах? ____________________________ С уважением, Лисеев Дмитрий. 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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/13852a3e91d01.html, оценка из 5, голосов 10
|
|
|