Опросы
Активных опросов на данный момент нет.
Счетчики
Rambler's Top100





Яндекс цитирования


Rambler's Top100
Статьи » Литера N
А  Б  В  Г  Д  Е  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Э  Ю  Я
0-9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z

Я проектировал базу данных таким образом, чтобы она не выдавала ошибок
блокировки вообще, а в случае возникновения конфликтов ждала, пока
блокирующая транзакция завершится, и продолжала свою работу (разумеется о
deadlock'ах здесь речь не идет, когда две транзакции взаимоблокируются,
ожидая окончания друг друга, т.к. в нормально спроектированной базе такого
быть не должно). Для этих целей все транзакции должны стартовать с
параметром WAIT и быть максимально быстрыми, чтобы надолго не блокировать
работу других конкурентных транзакций. Очевидно, что уровень изоляции
SNAPSHOT для транзакций, изменяющих данные, в данном случае не подойдет.
Решено было остановится на READ COMMITTED RECORD_VERSION. Прочитав много
разных статей и документацию я был убежден, что такая транзакция, запущенная
с параметром WAIT, в случае попадания на конфликт при изменении данных будет
ждать окончания блокирующей транзакции, и независимо от того, чем та
закончится - COMMIT или ROLLBACK, продолжит свою работу по изменению этих
данных. Все оказалось не так. Транзакция READ COMMITED RECORD_VERSION WAIT
действительно может изменять данные, которые были изменены другой
транзакцией, стартовавшей позже, и подтверждены по COMMIT, но только в том
случае, если подтверждение было раньше, чем первая транзакция приступит к
изменению этих данных и попадет на конфликт и последующее ожидание. Если
случится конфликт, то в случае если блокирующая транзакция откатится,
ожидающая транзакция сможет изменить данные и продолжит свою работу, однако
если блокирующая транзакция подтвердится, то ожидающая транзакция вместо
того, чтобы увидеть подтвержденные данные и изменить их снова, выйдет по
ошибке deadlock, что является странным для READ COMMITTED транзакции. В этом
случае ее поведение ничем не отличается от транзакции SNAPSHOT и
практическое применение параметра WAIT кажется сомнительным.

 
 
© 2018