 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 24 Dec 2002 16:57:23 To : Sergey Prach Subject : Re: Синхронизация дос тупа к БД -------------------------------------------------------------------------------- Hello, Sergey Prach! You wrote to Sergey Vlasov on Mon, 23 Dec 2002 22:07:46 +0000 (UTC): >> В многоверсионной архитектуре - можно. Транзакция в этом случае видит >> данные в том состоянии, в котором они были на момент ее начала (плюс >> свои изменения, если они были). SP> Вот только фишка будет в том, что это за данные будут на момент SP> окончания транзакции, если паралельная модифицирующая транзакция SP> закомитила их раньше, чем транзакция RO. Выше написано. Специально подчеркиваю - результат _вообще никак_ не зависит от наличия и действий параллельных транзакций. >>> В противном случае отчет будет некорректным. >> Будет корректным, но будет отражать состояние на момент начала >> транзакции. SP> Вот тут то и вылазит колизия на уровне SP> приложения, для неопытного разарботчика: если в отчете проставляется SP> дата и время его формирования, то обычно там стоит дата окончания SP> формирования отчета, а не начала выполнения. Это коллизия не только для очень неопытного, но и для.. не очень умного, так скажем. Который не в состоянии понять такую простую вещь, что дата должна соответствовать старту транзакции, а не коммиту. SP> Если паралельная транзакция успела модифицировать данные раньше, SP> чем генератор отчета получил последнюю строку данных, то на SP> прикладном уровне вылазит колизия. Вредо бы все просто решается - SP> надо проставить дату и время запуска ХП, но тогда возникает другой SP> вопрос: а где гарантия, что сервер начал обработку ХП сразу, SP> а не после некоторой "разгрузки" очереди запросов? Старт транзакции и начало обработки - в общем случае не одно и то же. Да, в большинстве серверов на анализ условий и наложение соответству- ющих блокировок уходит время. Hебольшое, и с этим придется смириться. >> При SERIALIZABLE фактически делается снимок состояния на >> момент начала транзакции - это позволяет корректно обработать отчет, >> требующий более одного SELECT. Еще раз подчеркиваю, что даже при >> уровне SERIALIZABLE, если производится только чтение, такая >> транзакция никому не мешает (ни чтению, ни обновлениям из других >> транзакций). SP> Тоже не совсем верно. При SERIZABLE снимок не делается, а SP> формируется по мере выполнения транзакции. Т.е. если какие-либо SP> данные будут запрашиватся только в конце долгоиграющей траназкции, SP> то и снимок для них будет сделан только в конце этой транзакции. Это обсудим параллельно, в ответе на письмо в мой адрес... --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/64889f15e2c8.html, оценка из 5, голосов 10
|
|
|