Блокировки на Postgres в "автоматическом режиме". Было ли изменение поведения?
От сдающих экзамен 1С:Эксперт "проскочила" информация что изменилось поведение при установке блокировки на Postgres в "автоматическом режиме" (фактически не происходит блокировки всей таблицы).
Собственно само сообщение с форума чистова.
Кто нибудь в курсе этих изменений ???
Сам я пробовал проверить на PostgreSQL 9.6.3 64-bit + 1С 8.3.10.2561. Собственно в автоматическом режиме на таблицах регистров устанавливалась Share блокировка (Защищает от параллельного изменения данных) т.е. блокировка таблиц сохранилась.
Собственно само сообщение с форума чистова.
На экзамене вышел один из сдающих, ему попался билет по блокировкам на Postgres в различных режимах, он ответил что "в автоматическом режиме - вся таблица", на что Виктор Богачев сказал, ответ не верный, поведение изменилось, информация в документации устарела
Кто нибудь в курсе этих изменений ???
Сам я пробовал проверить на PostgreSQL 9.6.3 64-bit + 1С 8.3.10.2561. Собственно в автоматическом режиме на таблицах регистров устанавливалась Share блокировка (Защищает от параллельного изменения данных) т.е. блокировка таблиц сохранилась.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Либо кто-то кого-то неправильно понял, либо Богачев обладает уникальной информацией, не отраженной в списках изменений релизов.
Строго говоря, по факту и на MSSQL в serializable в типовой почти нереально проводить параллельно.
Строго говоря, по факту и на MSSQL в serializable в типовой почти нереально проводить параллельно.
Собственно изменения в поведении все же есть.
До 9.1 при чтении данных в транзакции накладывалась ApplicationShareLock блокировка , а при записи ApplicationExclusiveLock.
ApplicationShareLock совместима только с ApplicationShareLock (если не принимать во внимание др. режимы).
Т.е. фактически "читатели блокировали писателей", а "писатели блокируют читателей и писателей".
На >= 9.1 при чтении данных в транзакции накладывается ShareLock блокировка (защищает табл. от параллельного изменения данных), а при записи ExclusiveLock (параллельно допускает только чтение таблиц).
Получается что "писатели не блокируют читателей".
До 9.1 при чтении данных в транзакции накладывалась ApplicationShareLock блокировка , а при записи ApplicationExclusiveLock.
ApplicationShareLock совместима только с ApplicationShareLock (если не принимать во внимание др. режимы).
Т.е. фактически "читатели блокировали писателей", а "писатели блокируют читателей и писателей".
На >= 9.1 при чтении данных в транзакции накладывается ShareLock блокировка (защищает табл. от параллельного изменения данных), а при записи ExclusiveLock (параллельно допускает только чтение таблиц).
Получается что "писатели не блокируют читателей".
(3) Фигня. Эксклюзивная блокировка при записи не может позволять параллельное чтение по определению. Это во-первых.
А во-вторых, если бы такое было возможно, то в автоматическом режиме блокировок ты приплываешь на потерю консистентности данных.
Более того, суть-то проблемы в том, что простого взаимного блокирования читателей и писателей на разделяемых записях НЕДОСТАТОЧНО для обеспечения уровня изоляции SERIALIZABLE, требуемого для обеспечения консистентности в автоматическом режиме блокировок. Иначе бы и не было необходимости таблицы блокировать в постгри.
А во-вторых, если бы такое было возможно, то в автоматическом режиме блокировок ты приплываешь на потерю консистентности данных.
Более того, суть-то проблемы в том, что простого взаимного блокирования читателей и писателей на разделяемых записях НЕДОСТАТОЧНО для обеспечения уровня изоляции SERIALIZABLE, требуемого для обеспечения консистентности в автоматическом режиме блокировок. Иначе бы и не было необходимости таблицы блокировать в постгри.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот