Когда бы вы использовали оптимистическую блокировку Hibernate вместо сериализуемого уровня изоляции postgres?

Добрый день, я понял, что такое сериализуемый уровень изоляции и чем он отличается от REPEATABLE READ в Postgres. Сериализуемая транзакция способна обнаруживать циклы чтения и записи, поэтому только первая фиксация будет успешной.

Имея это в виду, имеет ли смысл использовать Hibernate's оптимистическую блокировку, основанную на управлении версиями строк? Управление версиями строк будет вести себя точно так же, если столбец версии был обновлен, будет выдано исключение Java, которое отменит транзакцию. Кроме того, согласно вики Postgres, триггер должен быть создан, если некоторые обновления были сделаны вне код уровня приложения (например, простой sql-запрос, выполняемый psql). Так что, по моему скромному мнению, уровень Serializable — это замена оптимистической блокировки, так ли это, или есть некоторые случаи использования, когда вместо этого вы бы предпочли оптимистическую блокировку?


postgresql java hibernate optimistic-locking
person Almas Abdrazak    schedule 21.06.2021    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Не путайте REPEATABLE READ и SERIALIZABLE: последний сильнее первого, а первый не требует дополнительных затрат на производительность. REPEATABLE READ достаточно для оптимистичной блокировки.

Обычно я предпочитаю оптимистическую блокировку с помощью методов базы данных, так как это будет дешевле. Однако есть один случай, когда я бы предпочел оптимистическую блокировку на стороне приложения: если результирующая транзакция базы данных займет много времени.

С REPEATABLE READ вы должны выполнить SELECT и последнее UPDATE в одной и той же транзакции базы данных. Теперь транзакции должны быть короткими, чтобы база данных работала хорошо, поэтому, если, например, задействовано взаимодействие с пользователем, использование транзакций REPEATABLE READ будет неэффективным.

Если вы хотите знать, что плохого в длинных REPEATABLE READ транзакциях:

  1. они удерживают блокировки, потенциально блокируя одновременную активность на неопределенный срок (представьте, что вы хотите запустить ALTER TABLE в этой базе данных)

  2. они препятствуют прохождению автоочистки, тем самым раздувая ваши таблицы

person Laurenz Albe    schedule 22.06.2021