Пессимистическая блокировка в худшем случае

Мы используем Java EE. И делаем приложение, в котором в худшем случае большое количество сообщений очереди сообщений будет поступать от одного и того же пользователя.

Поэтому мы рассматриваем пессимистическую блокировку в стиле SELECT FOR UPDATE. Что в теории и при первых тестах решает наши проблемы.

Но мы боимся тупиков. Не классические: пользователь X блокирует A, пользователь Y блокирует B. Но больше сценариев, таких как: сбой системы, проблемы с сетью и т. д. Система базы данных блокируется по неизвестной причине. Мы будем использовать современные базы данных, такие как: oracle, MS SQL и postgresql.

Что мы хотели бы знать, используется ли пессимистическая блокировка в продакшене и какие практические проблемы можно ожидать?

Заранее спасибо!


locking pessimistic-locking
person user21549    schedule 21.03.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Другими словами, при условии, что ваш код предотвращает взаимоблокировки (как вы говорите в своем посте) на уровне приложения, производительность становится проблемой - пропускная способность падает, поскольку только 1 пользователь за раз может выполнять обновление данного набора данных.

Возможно, что заблокированная таблица останется заблокированной, если произойдет системное исключение, при котором select for update будет выполнено, но не зафиксировано, но в целом это не является обычным явлением (хотя это, очевидно, зависит от вашего кода). Однако я не видел, чтобы это происходило из-за проблемы, связанной с инфраструктурой, только из-за ошибок приложения.

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

person Sean Landsman    schedule 21.03.2013