Если бы любая транзакция работала на Повторяемом уровне изоляции Чтения, то обоим разрешили бы фиксировать; но с тех пор нет никакого последовательного порядка выполнения, согласовывающегося с результатом, использование Сериализуемых транзакций позволит одной транзакции фиксировать и будет откатывать другой с этим сообщением:
Там приводится пример аномалии которая отработает при уровне Read Commited и не отработает на уровне SERIALIZE. Как я понял вы такой пример и хотели? Или я не правильно понял?
Дмитрий, то, что нужно спасибо.
А почему в доках написано, что аномалия сериализации невозможна только на serializable уровне?
Я такой пример выполняю:
В первом соединении (первая транзакция)
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
UPDATE amounts SET
amount = amount + 100
WHERE id = 1;
Во втором соединении (вторая транзакция)
START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
UPDATE amounts SET
amount = amount + 200
WHERE id = 1;
и ждем пока первая транзакции не выполнится. Делаем commit первый транзакции, она фиксируется, зато вторая отваливается с ошибкой: ОШИБКА: не удалось сериализовать доступ из-за параллельного изменения.
Получается аномалия сериализации на уровне repeatable read тоже недопустима?
Дмитрий, я тестирую в PostgreSQL.
Меня, смущает формулировка : ОШИБКА: не удалось сериализовать доступ из-за параллельного изменения.
Это как я понял и есть аномалия сериализации.
На самом деле этот уровень изоляции работает точно так же REPEATABLE READ за исключением того, что это контролирует для условий, которые могли заставить выполнение параллельного набора сериализуемых транзакций вести себя способом, несовместимым со всем возможным сериалом (по одному) выполнение тех транзакций. Этот контроль не представляет блокирования, кроме того существующего в REPEATABLE READ, но существуют немного служебные к контролю, и обнаружение условий, которые могли вызвать аномалию сериализации, инициирует отказ сериализации.
Простой
