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

При этом, в многопоточной среде не каждая транзакция может завершиться нормально. Спринг не предоставляет "из коробки" решений, чтобы делать retry, но где-то в гугле нашел, что это можно делать аспектом, и вышло как-то так:




Использую так:




Вопрос - каким экзепшенам в моем аспекте надо делать catch()?

Я попробовал - если обьект не лочить и он изменился в двух потоках, то первый коммитит, а второй бросает нечто, что оборачивается в JpaOptimisticLockingFailureException. Но. Если мы в двух потоках вставляем обьект с одинаковым id, то бросается уже MySQLIntegrityConstrainsViolationException которое дойдя до нашего catch будет тыщу раз обернуто, и словится как JpaSystemException. То есть, retry я имею право делать, только если внутри сидит MySQLIntegrityConstrainsViolationException.

При этом, если мы ставим на обьект пессимистическую блокировку, то ловится уже NucleusDataStoreException (я использую datanucleus а не хибернейт)

То есть, я моделирую разные ситуации конкурентного доступа к обьекту и сижу ловлю экзепшены, составляя их список, чтобы потом сделать catch в моем аспекте. Но есть подозрение, что я делаю что-то не то, что я что-то не учту и мой список будет не полным. Либо уже такой список где-то есть (найти не удалось), либо это делается как-то по другому - но как?

Да, судя по документации это так. Но вопрос не в этом.

Вопрос в том, что есть исключения, при которых retry делать вообще нет смысла. Например NPE, исключения которые возникли по вине неверных данных, по вине программиста и тд.

А есть такие, что связаны именно с тем, что был конкурентный доступ к одинаковым Entity - и для таких retry скорей всего сработает.

И я хочу расставить catch() в своем аспекте так, чтобы он без retry выпускал наверх все исключения, кроме тех, для которых можно сделать retry.

Т.е., меня не волнует райнтайм оно или нет.

К сожалению, не все так просто. Экзепшенов получается больше.

Щас смотрю код спринга - есть набор экзепшенов по умолчанию, есть тот, что зависит от JpaDialect - в моем случае он стоит в default. И есть еще некий PersistenceExceptionTranslator. Пока не разобрался как их назначить.

Кстати, неясно зачем вообще оборачивать стандартные экзепшены (которые уже рантайм!) в свои обертки. Ладно еще, если это было бы что-то экзотическое, но стандартное-то зачем. ИМХО, это вообще антипаттерн.

авторВообще это довольно-таки опасно, если сущность изменилась то ретрай может нагородить делов

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