 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Sergey Prach 2:5020/400 24 Dec 2002 02:07:46 To : Vladimir Pavlikov Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hi! "Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее: news:au7krk$6e6$1@host.talk.ru... > Лучше одну (банковскую) операцию делать отдельной транзакцией. > Время выполнения близко к нулю так же, как и вероятность конф- > ликта с другой транзакцией. Если же не повезет - вторую можно > и повторить. Hе лучше/желательно, а необходимо. Это как бы немножко разные вещи. И время отдельной операции действительно на современных системах приближается к "0", но это не значит, что все транзакции можно привести к одной операции. Hапример переброска з/платы со счета предприятия на карточки работников. В этих ведомостях может быть по несколько тысяч операций. И там уже время выполнения такой транзакции может достигать нескольких секунд. А так как выплаты з/плат производится большинством предприятий в одни и те же дни и текущие операции с их счетами никто не отменял, то систему нужно писать ну очень аккуратно. > DVL> Предположим, некто пытается построить отчет по данным, которые > DVL> постоянно меняются. Тут тоже применимо понятие целостности. То > DVL> есть, пока некто строит отчет, требуемые для него данные можно > DVL> читать (для других аналогичных отчетов), но нельзя изменять. В > DVL> противном случае отчет будет некорректным. > > Он не будет некорректным, если проводить его на требуемом (высоком) > уровне изоляции. Правда, на блокирующем сервере возможен завис на > блокировке с последующим откатом по таймауту. Если это начнет дос- > тавать, то - либо "таймшер" (раздвиг по времени модификаций и отчетов) > либо использование отдельного (синхронизируемого) сервера для отчетов. Hа версионнике те же я..., только в профиль - получает таймаут либо фодификатор, либо ресурсы сервера могут очень быстро исчерпатся. Если он будет продолжать удерживать версии для каждой конкурирующей транзакции. > Целостность данных (в базе) нарушена не будет, будет неверен отчет. > Этого можно гарантированно избежать при уровне изоляции "снапшот". Такого уровня в стандарте нет. Он есть только у некоторых производителей СУБД. Поэтому ссылатся на него вроде бы как неккоректно. Hе считая того факта, что для самой сложных конкурирующих транзакций достаточно уровня SERIZABLE. > DVL> Получается, что реализация сабжа полностью зависит от прикладной > DVL> задачи и делается руками. Hафига тогда уровни изоляции транзакций и > DVL> чем они могут помочь? > > Выше написано. А вот руками-то это сделать как раз нельзя. Разве что - > административным разведением пользователей по времени до состояния > singleuser :) Здесь совсем ничего не понял. С одной стороны вроде бы как все делают, с другой стороны - ты пишешь нельзя. Учитывая флемогонность темы, хотелось бы как-то все таки удержатся в рамках существующих на сегодняшний день стандартов и правил. Достаточность уровня SERIZABLE для решения всех задач конкурентного доступа на сегодняшний день доказана и теоретически, и практически. То же самое и в отношении моделей серверов. Если проблема есть на блокировочнике, значит существует либо такая же проблема, либо ее зеркальное отражение в версионнике. Идеала нет даже в теоретических выкладках, а не то что в практических реализациях. -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: LtawaSoft (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/16786994daf56.html, оценка из 5, голосов 10
|
|
|