Как уровень изоляции Repeatable Read, так и уровень изоляции Serializable могут приводить к возникновению ошибок, предназначенных для предотвращения аномалий сериализации. Как указывалось ранее, приложения, использующие эти уровни изоляции, должны поддерживать повторное выполнение транзакций, завершившихся со сбоем из-за ошибок сериализации. Текст сообщения о подобной ошибке будет варьироваться в зависимости от конкретных обстоятельств, но он всегда будет содержать код SQLSTATE 40001
(serialization_failure).
Также может быть целесообразным повторить попытку при возникновении взаимных блокировок.
Данные ошибки имеют код SQLSTATE 40P01
(deadlock_detected).
В некоторых случаях также уместно повторно выполнять транзакцию при ошибках нарушения уникальности ключа,
которые имеют код SQLSTATE 23505
(unique_violation), и при ошибках нарушения ограничений исключения, имеющих код SQLSTATE 23P01
(exclusion_violation). Например, если приложение выбирает новое значение для столбца первичного ключа после проверки текущих сохраненных ключей, может возникнуть ошибка нарушения уникальности ключа, так как другой экземпляр приложения одновременно выбрал тот же новый ключ. Фактически это является ошибкой сериализации, но сервер не обнаружит ее в данном качестве, поскольку он не может «видеть»
связь между вставляемым значением и предыдущими операциями чтения. Существуют также исключительные случаи, в которых сервер выдает ошибку уникальности ключа или нарушения ограничения исключения, даже если в принципе он обладает достаточной информацией для определения того, что первопричиной является проблема сериализации. Хотя рекомендуется просто
повторять выполнение serialization_failure ошибок безусловно,
при повторной обработке других кодов ошибок требуется большая осторожность, так как они
могут свидетельствовать о постоянных ошибочных состояниях, а не о временных
сбоях.
Важно повторить транзакцию целиком, включая всю логику, определяющую выбор SQL-запросов и используемых значений. Таким образом, Digital Q.DataBase не предоставляет механизм автоматического повтора, поскольку это невозможно сделать с гарантией корректности.
Повторная попытка выполнения транзакции не гарантирует, что транзакция будет завершена; может потребоваться несколько повторных попыток. В случаях с очень высокой конкуренцией за ресурсы возможно, что для успешного завершения транзакции потребуется множество попыток. В случаях, связанных с конфликтующей подготовленной транзакцией, продолжение работы может быть невозможно до тех пор, пока подготовленная транзакция не будет зафиксирована или отменена.