Использовал ли ты нотацию @Transactional

Что проверяют

Вопрос звучит как «да или нет», но проверяют глубину: понимаете ли вы, что аннотация работает через прокси, и сталкивались ли с её ловушками. Следом обычно спрашивают, откатится ли транзакция при checked-исключении и почему не сработал вызов из соседнего метода того же класса.

Как отвечать

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

• механизм: Spring оборачивает бин прокси, который открывает транзакцию до вызова и коммитит или откатывает после. Внутренний вызов this.method() проходит мимо прокси, и транзакция не открывается;
• откат: по умолчанию только на RuntimeException и Error. На checked-исключении транзакция коммитится, если не указать rollbackFor;
• propagation: по умолчанию REQUIRED, то есть присоединиться к текущей транзакции или открыть новую. REQUIRES_NEW приостанавливает внешнюю и открывает независимую, NESTED работает через savepoint JDBC;
• isolation: DEFAULT берёт уровень базы, у PostgreSQL это Read Committed, у MySQL InnoDB Repeatable Read;
• readOnly = true: подсказка. С Hibernate отключает flush и отслеживание изменений сущностей, на чтении это заметная экономия.

Хорошо добавить реальный случай: внешний HTTP-вызов внутри транзакции держал соединение, и под нагрузкой пул кончался. Решение: вынести вызов из транзакции или реагировать на событие через @TransactionalEventListener после коммита.

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

Где спотыкаются

Ловят исключение из вложенного REQUIRED-метода и продолжают работу. Транзакция уже помечена rollback-only, и на коммите внешнего метода вылетает UnexpectedRollbackException.

Путают org.springframework.transaction.annotation.Transactional с jakarta.transaction.Transactional: второй Spring тоже понимает, но в нём нет readOnly и уровней изоляции.

Вешают аннотацию на private-метод: прокси его не перехватит, и ошибки не будет. Со Spring 6 CGLIB-прокси покрывают также protected и package-private методы.