 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Sergey Prach 2:5020/400 24 Dec 2002 02:07:46 To : Sergey Vlasov Subject : Re: Синхронизация дос тупа к БД -------------------------------------------------------------------------------- Hi! "Sergey Vlasov" <vsu@mivlgu.murom.ru> сообщил/сообщила в новостях следующее: news:20021223204438.127aee13.vsu@mivlgu.murom.ru... > В многоверсионной архитектуре - можно. Транзакция в этом случае видит > данные в том состоянии, в котором они были на момент ее начала (плюс > свои изменения, если они были). В это как раз основной плюс > многоверсионности - параллельно может выполняться любое число > транзакций, только читающих данные, и они никак не мешают другим > транзакциям модифицировать данные. Вот только фишка будет в том, что это за данные будут на момент окончания транзакции, если паралельная модифицирующая транзакция закомитила их раньше, чем транзакция RO. > > > В противном случае отчет будет некорректным. > > Будет корректным, но будет отражать состояние на момент начала > транзакции. Правильно ты пишешь, это данные на момент начала транзакции. Только какими же ресурсами должен обладать сервер, что бы покрывать всех нужными версиями. Вот тут то и вылазит колизия на уровне приложения, для неопытного разарботчика: если в отчете проставляется дата и время его формирования, то обычно там стоит дата окончания формирования отчета, а не начала выполнения ХП. Если паралельная транзакция успела модифицировать данные раньше, чем генератор отчета получил последнюю строку данных, то на прикладном уровне вылазит колизия. Вредо бы все просто решается - надо проставить дату и время запуска ХП, но тогда возникает другой вопрос: а где гарантия, что сервер начал обработку ХП сразу, а не после некоторой "разгрузки" очереди запросов? > Hапример, в PostgreSQL (версионник) поддерживаются уровни READ > COMMITTED и SERIALIZABLE. При READ COMMITTED каждая отдельная команда > видит завершенные транзакции на момент начала выполнения этой команды > (т.е. в этом случае два последовательных одинаковых SELECT могут > выдать разные результаты - вот как раз в этом случае "баланс не > сведется", если для генерации отчета нужно выполнить более одного > запроса). При SERIALIZABLE фактически делается снимок состояния на > момент начала транзакции - это позволяет корректно обработать отчет, > требующий более одного SELECT. Еще раз подчеркиваю, что даже при > уровне SERIALIZABLE, если производится только чтение, такая транзакция > никому не мешает (ни чтению, ни обновлениям из других транзакций). Тоже не совсем верно. При SERIZABLE снимок не делается, а формируется по мере выполнения транзакции. Т.е. если какие-либо данные будут запрашиватся только в конце долгоиграющей траназкции, то и снимок для них будет сделан только в конце этой транзакции. -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: LtawaSoft (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/1678648cf3e2b.html, оценка из 5, голосов 10
|
Re: Синхронизация дос тупа к БД 
|
|