Spring Data и транзакции

Репозитории и где проходит граница транзакции

Spring Data убирает шаблонный код доступа к базе: ты объявляешь интерфейс репозитория, а реализацию генерируют. Запрос собирается прямо из имени метода - findByEmailAndStatus превращается в условие по двум полям; сложное пишут в @Query; постраничную выдачу даёт параметр Pageable.

@Transactional работает через прокси - обёртку, которой Spring подменяет твой объект при создании: она открывает транзакцию до вызова метода, коммитит после и откатывает при ошибке. Значит, действуют все прокси-правила: перехват работает на публичном методе бина, вызванном СНАРУЖИ. Я это проверил на живом контексте - при вызове через this в логе не появилось ни открытия, ни коммита.

// Границу транзакции обычно держат на сервисном методе, а не в репозитории. Транзакцией должна владеть бизнес-операция целиком, чтобы несколько запросов к базе были неделимы - иначе половина операции закоммитится, а половина нет.

запрос из имени метода

findByEmailAndStatus - условие собирается по названию

@Transactional

прокси открывает, коммитит и откатывает транзакцию вокруг метода

Что откатывает транзакцию, а что нет

Замер целиком. Метод упал с IllegalStateException - в логе ROLLBACK. Метод упал с обычным Exception - в логе COMMIT. Тот же метод с настройкой @Transactional(rollbackFor = Exception.class) - снова ROLLBACK.

Правило такое: по умолчанию откат происходит только на непроверяемых исключениях, то есть наследниках RuntimeException и Error. Проверяемое исключение - то, которое компилятор требует объявить или поймать - считается штатным исходом, и транзакция коммитится. Дефолт этот достался Spring по наследству от старого стандарта серверных компонентов, логики в нём для сегодняшнего кода немного, поэтому его просто надо помнить.

Propagation отвечает на вопрос «что делать, если транзакция уже открыта». REQUIRED, значение по умолчанию, присоединяется к текущей - в моём замере вложенный вызов НЕ создал вторую транзакцию, лог показал одно открытие на оба метода. REQUIRES_NEW приостанавливает текущую и открывает независимую: у меня в логе появилось второе открытие, вложенный метод закоммитился сам, и лишь потом завершился внешний. Так делают аудит и логи, которые должны пережить откат основной операции.

@Transactional void a() { throw new IllegalStateException(); }  // ROLLBACK
@Transactional void b() throws Exception { throw new Exception(); }  // COMMIT (!)

@Transactional(rollbackFor = Exception.class)
void c() throws Exception { throw new Exception(); }             // ROLLBACK

rollbackFor

откатывать и на проверяемых исключениях, а не только на непроверяемых

REQUIRES_NEW

приостановить текущую транзакцию и открыть независимую

Пометка rollback-only: когда «поймал и продолжил» не спасает

Тут я проверил два похожих случая, и они ведут себя ПО-РАЗНОМУ. Случай первый: метод поймал собственное исключение и пошёл дальше. Результат - обычный COMMIT, никаких сюрпризов. Случай второй: метод позвал ДРУГОЙ транзакционный бин, тот упал, а внешний метод исключение поймал и продолжил. Результат - UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only.

Разница в том, кто пометил транзакцию. Когда падает вложенный транзакционный метод, присоединившийся к той же транзакции, прокси не может откатить её частями - и помечает всю транзакцию как «только откат». Внешний метод об этом не знает, доходит до конца, и на попытке коммита получает отказ. Твой собственный try-catch внутри одного метода такой пометки не ставит.

// Практический вывод: ловить исключения от соседних транзакционных бинов и делать вид, что всё хорошо, нельзя. Нужна операция, которая переживёт падение соседа - вызывай её с REQUIRES_NEW, тогда у неё будет своя транзакция и своя судьба.

// поймал СВОЁ исключение внутри метода:
//   BEGIN ... COMMIT, ошибок нет

// поймал исключение ВЛОЖЕННОГО транзакционного бина:
//   BEGIN ... ! помечено rollback-only ... ROLLBACK
//   UnexpectedRollbackException: Transaction rolled back
//   because it has been marked as rollback-only

rollback-only

пометка «эту транзакцию можно только откатить»

UnexpectedRollbackException

коммит отклонён, потому что транзакция уже помечена на откат

Как отвечать: «Почему транзакция не откатилась, хотя вылетело исключение?»

Первым делом смотрю на тип исключения. По умолчанию Spring откатывает только на непроверяемых - на RuntimeException и Error, а проверяемое считается штатным исходом и транзакция коммитится. Я это проверял с подменным менеджером транзакций: то же самое падение с RuntimeException дало ROLLBACK, а с Exception - COMMIT. Лечится настройкой rollbackFor = Exception.class. Второй частый случай - исключение поймали внутри и проглотили: прокси про ошибку не узнал и честно закоммитил. Третий - вызов через this: транзакции не было вовсе, в логе при таком вызове вообще пусто, откатывать нечего. И отдельно держу в голове обратную ситуацию: если упал вложенный транзакционный метод, а я поймал его исключение, транзакция уже помечена только на откат, и мой коммит упадёт с UnexpectedRollbackException.

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

На чём валят

• −Ждать отката на проверяемом исключении. По умолчанию его нет - нужен rollbackFor.
• −@Transactional на приватном методе или на вызове через this. Транзакции не будет, и в логе не появится ни строчки.
• −Поймать исключение соседнего транзакционного бина и продолжить. Транзакция уже помечена на откат, коммит упадёт с UnexpectedRollbackException.
• −Ставить REQUIRES_NEW «на всякий случай». Это два соединения с базой на один запрос и риск исчерпать пул.
• −Звать чужой сервис по сети внутри транзакции. Соединение с базой простаивает всё время ожидания, под нагрузкой пул кончается.