Я не очень понимаю зачем здесь тема БД выпячивается наперед. Шаблон Retry используется очень широко.
И это не к БД относится а к приложению. Мы использовали обычно Guava Retrying with exponential back-off
вот как в примерах пишут
https://github.com/rholder/guava-retrying и это примениме не только к БД
а к любым внешним API (Rest/SOAP e.t.c.). Эта механика работае почти везде. Ей много лет и она
воплощена многих сетевых протоколах а не только в приложениях.
По поводу настроек БД. Я могу рассказать про Oracle. Update использует специальный неблокирующий
синтаксис NOWAIT
SELECT .... FOR UPDATE NOWAIT;
который мгновенно возвращает ошибку если не удалось захватить сет строк для обновления. Это подходит
для работы с UI и толстым клиентом например или с веб клиентом.
Например для джоба которы должен работать ночью и взяв например
1000 клиентов или фирм и обработать - предпочтителен подход блокировки всего курсора
SELECT .... FOR UPDATE;.
В этом случае другие джобы будут стоять в ожидании.
А для дневной OLTP активности лучше брать корткие операции с NOWAIT. Проконсультируйтесь с вашей
документацией по вашей БД поддерживается ли неблокирующая операция.
Еще посмотрите видео от Филиппа Дельгядо. Он рассказывал как работали с очередями в Postgres,
там есть интересные режимы блокировок когда не "все или ничего" а есть какой-то компромиссный
режим.
Вообще Retry и защита от перегрузок это броня и снаряд. Как DDOS. Если вы с одной стороны внедряете Retry то с другой
стороны люди начинают плакать и стонать от ваших ретраев до тех пор пока не поставят
вам троттлер или аварийный размыкатель.
Короче думайте о последствиях.
