Есть сущности менеджера и роли, связь многие к одному. https://pastebin.com/ficbRs1U В

сервисе есть метод загрузки менеджеров в БД, который принимает лист ДТОшек, в нём происходит следующее:
1. кидается исключение, если в листе есть дупликаты
2. из таблицы ролей строится мапа название_роли - роль (Map <String, Role>)
3. удаляются все записи из таблицы менеджеров в БД
4. входящие ДТО мапятся в сущность ClientManager, менеджер добавляется в список менеджеров для соответствующей роли и ему сетится роль, если она есть
5. весь лист менеджеров сохраняется в БД

Проблема в том, что между 3 и 5 пунктами может войти менеджер (есть интеграция с другой системой, поэтому это возможно), он запишется в таблицу и произойдёт так, что будет дубль в БД.

Как это можно решить? Используется Spring Data JPA

Это какой-то странный алгоритм работы, особенно очищение всего. Обновлять нельзя? Если в лоб решать - залочьте всю таблицу и работайте спокойно. Если операция нечастая, а на таблицу не дофига всего завязано, то должно прокатить.

Согласен. Вообще переписать стоит. А если залочить, то в потом методе ловить соответсвующее исключение и не пускать пользователя?

В смысле? Есть шанс, что транзакция у других пользователей просто “зависнет” и другие сессии будут ждать, пока вы отпустите таблицу. Зависит от реализации блокировок в СУБД и JDBC драйвере. Но я бы так не делал, это уж совсем жесть. На вашем месте сначала бы попробовал разобраться, что в алгоритме делается.

select for update + timeout (ОБЯЗАТЕЛЬНО) + ручная проверка дублей и кастомная обработка

А можно поподробнее, пожалуйста? Что почитать можно?

optimistic locking Pessimistic locking Query timeout Transactional outbox pattern Deadlock

Повесил на метод аннотацию @Transactional, аннотацию @Lock(LockModeType.PESSIMISTIC_WRITE), чтобы БД предотвратила чтение и запись сущности любой другой транзакцией. Тогда если попытаться прочитать, то через указанный таймаут возникнет исключение. 1) Я нигде не ошибаюсь? 2) Как понять, какой таймаут ставить? 3) Кастомная обработка == обработка лок эксепшнов, чтобы на фронте показывали "попробуйте позже"?

вторая аннотация ставится на метод в jpa репозитории

таймаут скорее всего придется ставить через нативный запрос и квэри хинты

А чего вы хотите сделать-то? Все ещё таблицу залочить?

select for update с timeout банальный

Так там изначально было всю таблицу заблокировать, очистить и потом в нее что-то записать. И никто не должен был в нее ничего не дописать

Решить проблему, что когда через админку грузят справочник (=полностью чистят и заполняют из csv в таблицу БД), то в промежуток между удалением и заполнением может прийти пользователь и записать себя в таблицу, а потом при записи будет дубль уникальных полей Мне в голову пришло несколько вариантов: 1. залочить таблицу. но тогда надо как-то на фронте пользователю сообщать что происходит 2. метод в транзакции, пользователи просто будут читать старые данные из БД пока транзакция незакоммичена и работать как ни в чём ни бывало. Но тогда придётся всегда перед сохранением идти в БД и читать id оттуда

@dmsol вот не уверен, что select * for update предотвратит вставку. Я лично вижу только один надежный способ - лочить таблицу и пусть весь фронт подождет. Аккуратно отлавливать эксепшен того, что таблица занята. Второй способ, если СУБД позволяет - делать MERGE или UPSERT - зависит от вендора. И третий способ - я считаю, что вот так вот полностью вычищать таблицу и заново заполнять - это больная фантазия. Я бы 100 раз подумал, прежде, чем такой алгоритм делать. Что у вас там такое, что надо все полностью вычищать?

Справочник менеджеров. Файл - это некий эталон, там всегда актуальные и полные данные. Например, файл отдают партнёрам и они просто добавляют туда своих менеджеров и отправляют обратно, а его уже грузят "Это не моя идея, это всё бизнес"

так sfu как раз про блокировку

Я про вставку. Ну сделал ты SFU на существующие записи, но не факт, что это предотвратит вставку новых.

предотвратит дубликат

Это да, тут согласен.

У меня в методе происходит вызов deleteAllInBatch()+save(). Думаю тогда можно создать метод-объединение в jpa репозитории и на него повесить @Query+@Lock+@QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value = "1000")}) же?

я не понял про метод объединение, прочитай про эти аннотации и что они делают