Что каждый разработчик должен знать об аннотации @Transactional

Оглавление

1. Введение
2. Основы работы @Transactional: механизмы Spring
3. Transaction propagation: поведение вложенных транзакций
4. Уровни изоляции транзакций (Isolation Level)
5. Поведение rollback: когда транзакция откатывается?
6. Ленивая загрузка (Lazy Loading) и границы транзакции
7. Сравнение с ручным управлением транзакциями (PlatformTransactionManager)
8. Типичные ошибки и анти-паттерны при использовании @Transactional
9. Советы по отладке и логированию транзакций
10. Заключение

Введение

В современных приложениях важно обеспечивать атомарность операций с данными. Если выполнение бизнес-логики включает несколько обращений к базе данных, они должны выполняться все как единое целое или не выполняться вовсе. Например, при переводе денег со счета покупателя на счет продавца нужно либо уменьшить баланс покупателя и увеличить баланс продавца, либо не делать ничего, если произошла ошибка. Транзакции как раз гарантируют принцип “все или ничего“: если в ходе выполнения операции возникает исключение, то все изменения откатываются, и база данных возвращается в консистентное состояние. Без транзакций частичное выполнение могло бы привести к потере данных или нарушению их целостности.

Spring Framework предоставляет удобный способ декларативного управления транзакциями с помощью аннотации @Transactional. Этой аннотацией можно пометить метод или класс сервиса, чтобы выполнить его логику внутри транзакции. Разработчику не нужно вручную открывать, коммитить или откатывать транзакцию – за него это сделает Spring. В результате код становится чище и безопаснее, а риск ошибок, связанных с неправильной работой с транзакциями, значительно снижается.

Стоит отметить, что в контексте Spring Boot (начиная с версий Spring Boot 3 и Spring Data JPA 3.5+ на базе Spring Framework 6) практически никакой дополнительной настройки для использования @Transactional не требуется. Если в вашем проекте есть зависимость spring-boot-starter-data-jpa (или любая другая, притягивающая модуль spring-tx), то поддержка транзакций включается автоматически. Spring Boot сам сконфигурирует нужный PlatformTransactionManager (например, JpaTransactionManager для JPA/Hibernate) и активирует управление транзакциями. В традиционных Spring-проектах без Boot раньше приходилось явно прописывать <tx:annotation-driven/> в XML или использовать @EnableTransactionManagement в конфигурации – в Spring Boot этого не требуется, все работает “из коробки”.

Аннотацию @Transactional чаще всего применяют к методам сервисного слоя (классам с @Service). Можно ставить ее как на весь класс (тогда все публичные методы класса будут выполняться в транзакции по умолчанию), так и на отдельные методы. Если @Transactional указана на классе, а на конкретном методе не переопределена, то метод наследует транзакционную политику класса. Spring Data JPA в своих репозиториях также использует @Transactional: по умолчанию все методы, выполняющие модификацию данных (например, save, delete) помечены транзакцией на запись, а методы чтения (например, findAll, findById) выполняются в транзакции с флагом readOnly=true. Это означает, что простые запросы через репозиторий выполняются в рамках кратковременной транзакции (чаще всего сразу завершаются после выполнения операции). Однако в прикладном коде рекомендуется открывать транзакции на уровне сервисов, особенно если операция объединяет несколько вызовов репозиториев. Внешняя транзакция на уровне сервиса перекрывает настройки транзакционности методов репозитория – например, если сервис помечен транзакцией read-write (по умолчанию), то даже вызовы методов репозитория, имеющих readOnly=true, будут выполняться в рамках общей read-write транзакции без ограничений на запись. Таким образом, @Transactional на уровне сервисов позволяет задать границы транзакции для группы операций и обеспечить целостность данных на уровне бизнес-логики.

Основы работы @Transactional: механизмы Spring

Как же Spring реализует поведение транзакций при помощи одной лишь аннотации? Ключ к пониманию – это AOP (Aspect-Oriented Programming), или аспектно-ориентированное программирование. Spring при старте приложения создает специальную прокси-обертку вокруг каждого бина, в котором обнаружена аннотация @Transactional (на классе или методах). Этот прокси берет на себя задачу перехватывать вызовы методов и выполнять дополнительный код до и после вашего метода. Упрощенно можно представить, что для транзакционного метода выполнение идет так:

1. До вызова реального метода: прокси обращается к менеджеру транзакций (PlatformTransactionManager) и открывает новую транзакцию (или присоединяется к существующей – об этом позже, в разделе про propagation). Для JPA это также означает открытие EntityManager (сессии Hibernate) и привязку ее к текущему потоку.
2. Вызов метода: ваш бизнес-код выполняется внутри открытой транзакции. Если в процессе выполнения произойдет необработанное исключение, Spring пометит транзакцию как требующую отката.
3. После возврата из метода: прокси перехватывает результат или исключение. Если метод завершился нормально (без исключений), прокси инициирует коммит транзакции – все накопленные изменения будут зафиксированы в базе данных. Если же произошло неперехваченное исключение, прокси выполнит откат транзакции (rollback). После коммита или отката Spring также закрывает EntityManager (сессию) и отвязывает его от потока.

Весь этот функционал инкапсулирован в инфраструктуре Spring. Разработчику достаточно поставить @Transactional – и Spring сам вызовет нужные методы begin(), commit() или rollback() в нужный момент. Это существенно упрощает код по сравнению с ручным управлением транзакцией через try-catch блоки.

Следует знать и о технических деталях реализации. Spring использует два вида прокси: динамические JDK-прокси и прокси на основе CGLIB. Если ваш транзакционный бин реализует какой-то интерфейс, по умолчанию Spring создаст прокси JDK, который реализует тот же интерфейс (и перехватывает вызовы интерфейсных методов). Если же интерфейса нет, будет использован CGLIB для создания подкласса вашего класса в runtime. В любом случае, прокси перехватывает вызовы на уровне контейнера Spring. Это означает, что только вызовы извне, проходящие через прокси, будут обернуты транзакцией. Если внутри того же класса транзакционный метод вызовет другой свой метод, помеченный @Transactional, то такой внутренний вызов не пройдет через прокси и, соответственно, второй метод не начнет новую транзакцию и не присоединится к существующей – аннотация будет проигнорирована. Этот распространенный подводный камень мы подробно рассмотрим далее, в разделе про типичные ошибки.

Еще одно ограничение: транзакцией по умолчанию оборачиваются только публичные методы. Методы private, пакетные (package-private) или protected – даже если они помечены @Transactional – не будут перехвачены прокси и выполнятся без транзакции. Таким образом, аннотацию имеет смысл ставить только на public методы сервисов. Как правило, это не проблема, так как бизнес-логика, требующая транзакции, обычно находится в публичных методах сервисного слоя. Но знать об этом необходимо, чтобы избежать скрытых ошибок.

Под капотом @Transactional работает благодаря API Spring Transaction Management. При открытии транзакции используется соответствующая реализация PlatformTransactionManager – для JPA/Hibernate это обычно JpaTransactionManager, который делегирует операции EntityManager’у JPA и JDBC-соединению. Он позаботится о том, чтобы применить нужные настройки из аннотации (уровень изоляции, read-only и т.п.) на уровне соединения с БД или ORM. Более того, Spring умеет объединять несколько транзакционных операций в одну: если транзакция уже открыта, новые вызовы с propagation = REQUIRED (по умолчанию) не создают новую физическую транзакцию, а участвуют в текущей. Эти нюансы мы рассмотрим далее.

Рис. 1: иллюстрация работы @Transactional в Spring (через AOP?прокси) для JPA/Hibernate

Резюмируя: @Transactional – это декларативный способ огородить кусок кода транзакцией. Spring через AOP-прокси автоматически запускает транзакцию в начале метода и управляет ее завершением (коммит или откат) по его окончании. Это позволяет сконцентрироваться на бизнес-логике, поручив инфраструктурные заботы фреймворку.

Transaction propagation: поведение вложенных транзакций

Когда несколько транзакционных методов вызываются один внутри другого, возникает вопрос – как они взаимодействуют между собой? Должен ли внутренний метод выполнить свою часть в рамках уже существующей транзакции, или начать новую независимую? А может, ему вообще не нужна транзакция? За это отвечает параметр propagation аннотации @Transactional. Propagation (способ распространения транзакции) определяет, что делать, когда вызов метода происходит в контексте уже существующей транзакции.

Spring поддерживает несколько режимов propagation (значения перечисления org.springframework.transaction.annotation.Propagation). Рассмотрим наиболее распространенные из них и их семантику:

• REQUIRED (по умолчанию) – метод должен выполняться внутри транзакции. Если на момент вызова уже есть активная транзакция, метод встраивается в нее (participates). Если же транзакции нет – Spring откроет новую. Этот режим удобен в большинстве случаев: внешние сервисы открывают транзакцию, а все вложенные вызовы разделяют общий контекст. Таким образом, все действия в цепочке либо коммитятся, либо откатываются вместе. Обратите внимание: участие во внешней транзакции означает, что локальные настройки аннотации (например, timeout, readOnly, isolation) будут проигнорированы – применятся параметры внешней транзакции. Вложенный метод может пометить транзакцию как rollback-only (например, выбросив исключение), что предотвратит коммит всей цепочки. Если внутренний метод вызвал откат, а внешний об этом “не знает” и попытается зафиксировать транзакцию, Spring бросит исключение UnexpectedRollbackException – оно сигнализирует внешнему вызову, что транзакция откатилась, несмотря на отсутствие явной ошибки с его стороны.
• REQUIRES_NEW – каждый такой метод всегда выполняется в новой, независимой транзакции. Если внешняя транзакция уже была, она будет приостановлена на время выполнения этого метода, а затем возобновлена после его завершения. Метод с REQUIRES_NEW всегда стартует свою физическую транзакцию, обособленную от внешней. Это означает, что коммит или откат внутренней транзакции никак не влияет на внешнюю: если внутренний метод упадет с исключением и откатится, внешняя транзакция все равно может продолжить работу и успешно зафиксироваться (ее “не заметит” откат вложенного метода). И наоборот, откат внешней транзакции не отменит уже зафиксированные изменения внутренних REQUIRES_NEW-транзакций. Такой режим полезен, когда нужно выполнить какую-то операцию изолированно. Классический пример – запись аудита или лога действий: основная транзакция может откатиться (например, из-за ошибки бизнес-логики), но запись о самом факте попытки (лог) хотелось бы сохранить. Метод логирования можно пометить Propagation.REQUIRES_NEW, и тогда он выполнится в отдельной транзакции, даже если основная не успешна. Важно помнить: REQUIRES_NEW требует открыть отдельное соединение к базе (так как предыдущее занято внешней транзакцией). Множество вложенных транзакций этого типа могут привести к исчерпанию пула соединений или даже дедлокам, если не рассчитать ресурсы. Например, если 10 потоков держат открытыми транзакции и каждый внутри вызывает REQUIRES_NEW, то понадобится еще 10 дополнительных соединений. Поэтому применять REQUIRES_NEW следует осознанно и при необходимости увеличивать размер пула соединений (хотя бы на количество параллельных вложенных транзакций плюс один).
• NESTED – метод выполняется в контексте вложенной транзакции с использованием механизма savepoint. В этом режиме Spring не открывает новую БД-сессию, а использует ту же самую физическую транзакцию, но помечает точку сохранения (savepoint) перед выполнением метода. Если вложенный метод бросает исключение, можно откатить его изменения до savepoint, не отменяя всю внешнюю транзакцию. Внешняя транзакция продолжится, будто ничего не произошло (откатываются только действия внутренней части). Это похоже на частичный откат. Однако, если внешняя транзакция сама решит откатиться, откатится все, включая внутренние операции. PROPAGATION_NESTED полезен в ситуациях, когда допустимо в рамках одной большой операции проигнорировать сбой в части работы, откатив только ее. Например, пакетная обработка нескольких записей: можно обернуть обработку каждой записи во вложенную транзакцию. При сбое на одной записи ее изменения откатятся до savepoint, но остальные обработки не пострадают. Важное ограничение: вложенные транзакции через savepoint поддерживаются только при использовании локальной транзакции на одном ресурсе (например, DataSourceTransactionManager с JDBC). Если платформа транзакций не поддерживает savepoint (типично для JPA в режиме JTA), то NESTED будет работать как REQUIRED или не поддерживаться вовсе. В контексте Spring Data JPA с Hibernate вложенные транзакции возможны, если использовать локальные JDBC-транзакции. Hibernate поддерживает savepoints при работе через тот же Connection.
• SUPPORTS – не обязывает выполнять метод в транзакции. Если транзакция уже есть – метод выполнится внутри нее; если нет – просто выполнится без транзакции (так называемый нетранзакционный контекст). Этот режим подходит для операций, которым не принципиальна транзакционность: они могут безопасно работать и в рамках существующей транзакции, и вне ее. Например, метод только читает справочные данные – можно пометить SUPPORTS, чтобы не открывать новую транзакцию зря, но позволить встроиться, если вызван из транзакционного контекста.
• NOT_SUPPORTED – всегда выполняет метод вне транзакции. Если на момент вызова есть активная транзакция, Spring ее приостанавливает на время выполнения текущего метода (аналогично REQUIRES_NEW, но без открытия новой транзакции). Таким образом, метод гарантированно выполнится без транзакционной обертки. Этот режим может понадобиться, если метод заведомо не должен участвовать в транзакции – например, длительная операция, во время которой не нужны транзакционные блокировки.
• MANDATORY – требует выполнение внутри существующей транзакции. Если при вызове метода транзакция отсутствует, Spring бросит исключение. Этот режим используется, когда метод на уровне логики не может работать без транзакции, и это явно контролируется. Например, метод низкоуровневого DAO, который предполагается вызывать только внутри сервисных транзакций.
• NEVER – противоположность MANDATORY: требует отсутствия активной транзакции. Если попытаться вызвать такой метод внутри транзакции, будет брошено исключение. Полезно для методов, которые должны выполняться только вне транзакционного контекста, чтобы избежать нежелательных побочных эффектов.

Сводная таблица по Propagation Levels

Propagation Level	Описание	Поведение при существующей транзакции	Поведение при отсутствии транзакции	Особенности / Применение	Пример использования
REQUIRED (по умолчанию)	Использует текущую транзакцию, или создает новую, если ее нет.	Присоединяется к текущей транзакции.	Открывает новую транзакцию.	Наиболее часто используемый режим; все операции выполняются в одной транзакции; внутренний метод может вызвать rollback всей цепочки.	Основная бизнес-операция: например, метод processOrder() в e-commerce, который обновляет заказ, уменьшает остаток товара и списывает деньги.
REQUIRES_NEW	Всегда создает новую транзакцию. Приостанавливает текущую (если есть).	Приостанавливает текущую, запускает новую.	Открывает новую транзакцию.	Полностью независимый коммит/откат; требует отдельного соединения; может вызвать рост нагрузки на пул соединений.	Логирование или аудит: сохранение записи о действии пользователя даже если основная транзакция откатится.
NESTED	Вложенная транзакция с savepoint внутри текущей.	Создает savepoint внутри текущей транзакции.	Открывает новую транзакцию (как REQUIRED).	При откате можно откатить только до savepoint, не трогая остальное; работает только при поддержке savepoints (обычно JDBC, не JTA).	Обработка пачки данных: при ошибке в одном элементе откатываем только его изменения, остальные продолжаем обрабатывать.
SUPPORTS	Выполняется в транзакции, если она есть.	Использует текущую.	Работает без транзакции.	Удобно для методов, которые могут работать и с транзакцией, и без неё.	Метод findById() в репозитории, который вызывается как внутри сервисных транзакций, так и в read-only режимах без транзакции.
NOT_SUPPORTED	Гарантированно выполняется вне транзакции.	Приостанавливает текущую.	Работает без транзакции.	Для операций, которые не должны выполняться в транзакции (например, длительные операции чтения без блокировок).	Генерация отчета, который долго обрабатывает данные и не должен блокировать записи в БД.
MANDATORY	Требует существующую транзакцию.	Использует текущую.	Бросает исключение.	Используется для методов, которые обязаны вызываться только в транзакционном контексте.	Низкоуровневая операция DAO, например updateBalance(), которая всегда вызывается только в рамках бизнес-транзакции.
NEVER	Запрещает выполнение в транзакции.	Бросает исключение.	Работает без транзакции.	Противоположность MANDATORY; для методов, которые никогда не должны выполняться в транзакции.	Отправка уведомлений по e-mail, которая не должна зависеть от состояния БД-транзакции.

Чтобы лучше понять разницу между PROPAGATION_REQUIRED и PROPAGATION_REQUIRES_NEW, рассмотрим наглядно их работу.

Ниже представлена диаграмма последовательности для поведения по умолчанию (PROPAGATION_REQUIRED). Метод B вызывается из метода A в одном потоке выполнения, и они будут разделять единую транзакцию. Метод B не открывает новую транзакцию, а использует контекст уже начатой транзакции A. Все операции обоих методов выполняются между одним begin и commit:

Рис. 2: иллюстрация работы PROPAGATION_REQUIRED

Следующая диаграмма показывает поведение при PROPAGATION_REQUIRES_NEW. Метод B всегда запускается в новой транзакции. Текущая транзакция A при вызове B временно приостанавливается. Метод B выполняется независимо – он открывает свою транзакцию, выполняет операции и фиксирует их (commit) или откатывает, не влияя на внешнюю транзакцию. После завершения B транзакция A возобновляется и продолжается:

Рис. 3: иллюстрация работы PROPAGATION_REQUIRES_NEW

Пример использования разных propagation

Рассмотрим небольшой пример, иллюстрирующий влияние propagation на результат. Пусть у нас есть сервис, выполняющий перевод со счета на счет, и внутри него вызывается метод обновления некого каталога (условно – обновление складских остатков после продажи). Мы хотим, чтобы ошибка при обновлении остатков не мешала основному переводу – т.е. деньги переводятся, даже если обновить склад не удалось. Код может выглядеть так:

@Service
public class PaymentService {
    @Autowired InventoryService inventoryService;
    @Autowired AccountRepository accountRepo;

    @Transactional
    public void processPayment(Long buyerId, Long sellerId, BigDecimal amount) {
        // списываем деньги со счета покупателя и зачисляем продавцу
        accountRepo.transfer(buyerId, sellerId, amount);
        try {
            inventoryService.updateStock(); // обновляем остатки товара
        } catch (Exception e) {
            // Логируем ошибку, но не пробрасываем её дальше,
            // чтобы перевод не откатился
            log.error("Failed to update stock!", e);
        }
    }
}

@Service
public class InventoryService {
    @Autowired InventoryRepository invRepo;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateStock() {
        invRepo.updateSomething();
        // ... какая-то логика
    }
}

Здесь основной метод processPayment запускается с пропагацией REQUIRED (так как это значение по умолчанию). Внутри него вызывается inventoryService.updateStock() с пропагацией REQUIRES_NEW. Это значит, что когда выполнение доходит до updateStock(), текущая транзакция перевода денег приостанавливается, и updateStock() выполняется в отдельной транзакции. Если в updateStock() возникает исключение, эта внутренняя транзакция откатится (мы перехватываем исключение, не давая ему прервать processPayment). Главное – внешний перевод денег не отменится, потому что он находится в другой транзакции, которая все еще активна и не помечена для отката. В итоге деньги будут переведены (внешняя транзакция успешно закоммитится), а обновление остатков – нет (оно откатилось). Благодаря REQUIRES_NEW сбой в независимой подсистеме (склад) не нарушил основную операцию.

Если бы мы использовали propagation REQUIRED для updateStock(), то при возникновении исключения в нем вся транзакция перевода была бы помечена на откат. Даже если поймать исключение, Spring все равно не позволит выполнить коммит и бросит UnexpectedRollbackException при завершении внешнего метода. В данном случае это нежелательно. Таким образом, правильный выбор propagation помогает реализовать требуемую бизнес-логику.

Уровни изоляции транзакций (Isolation Level)

Помимо правильного определения границ транзакций, каждый разработчик должен понимать, как параллельные транзакции влияют друг на друга. Представьте, что два пользователя почти одновременно выполняют операции с одними и теми же данными – например, оба читают и обновляют одну и ту же запись. Без должных ограничений возможны неприятные эффекты: один пользователь может прочитать промежуточные (незафиксированные) данные другого; или увидит разные данные при повторном чтении, если параллельно другая транзакция их изменила; или пропустит новую запись, добавленную параллельно, при повторном выполнении запроса. Эти эффекты известны как “грязное чтение” (dirty read), “неповторяемое чтение” (non-repeatable read) и “фантомное чтение” (phantom read).

Чтобы контролировать подобные ситуации, СУБД поддерживают различные уровни изоляции транзакций – набор правил, определяющих видимость изменений, сделанных одной транзакцией, для других параллельных транзакций. Spring позволяет задать желаемый уровень изоляции через параметр isolation аннотации @Transactional. Доступны стандартные уровни изоляции, определенные в SQL-стандарте (перечисление Isolation в Spring повторяет их):

• DEFAULT – использовать уровень изоляции по умолчанию, установленный в базе данных. Обычно это оптимальный выбор, если нет специальных требований. Например, в PostgreSQL по умолчанию используется READ COMMITTED, в MySQL – REPEATABLE READ. Spring в этом случае не будет явно менять уровень, полагаясь на настройки СУБД.
• READ_UNCOMMITTED – самый слабый уровень изоляции. Транзакция может видеть незакоммиченные изменения других транзакций. Допускаются грязные чтения, а также неповторяемые и фантомные чтения. На практике почти не используется, так как нарушает целостность данных, хоть и дает максимум производительности (за счет отсутствия блокировок на чтение).
• READ_COMMITTED – транзакция видит только данные, зафиксированные (committed) другими транзакциями. Грязные чтения невозможны (то есть нельзя прочитать изменения, которые другая транзакция потом отменила). Однако неповторяемые чтения и фантомы все еще возможны. Это один из самых распространенных уровней – он обеспечивает базовую консистентность при небольших накладных расходах. В частности, большинство СУБД (Oracle, PostgreSQL, MSSQL) по умолчанию работают на уровне READ COMMITTED.
• REPEATABLE_READ – более строгий уровень изоляции. Гарантирует, что если транзакция прочитала некоторое значение, то при повторном чтении в этой же транзакции оно останется таким же. Запрещает неповторяемое чтение: никакая другая транзакция не может изменить данные, которые мы уже прочли, пока текущая транзакция не завершится. Таким образом, все чтения в рамках одной транзакции повторяемы. Однако фантомные чтения все еще возможны – другая транзакция может вставить новые строки, удовлетворяющие условиям вашего запроса (так называемые фантомы). В MySQL (InnoDB) уровень по умолчанию – REPEATABLE_READ (где, к слову, механизм next-key locking предотвращает фантомы в рамках диапазонных запросов). Для большинства приложений этого уровня изоляции достаточно: он обеспечивает довольно сильные гарантии консистентности данных.
• SERIALIZABLE – самый строгий уровень изоляции. Транзакции выполняются так, будто последовательно, одна за другой, а не параллельно. Полностью исключает грязные, неповторяемые и фантомные чтения. Достигается это, как правило, за счет более жестких блокировок (например, блокировки на чтение всех диапазонов данных, участвующих в запросах) или за счет многоверсионного контроля с проверкой конфликтов при фиксации. SERIALIZABLE гарантирует максимальную целостность данных, но может существенно снизить производительность из-за блокировок и потенциальных откатов транзакций при обнаружении конфликтов. Применяется только там, где данные критически важны и небольшое снижение параллелизма допустимо.

В Spring уровень изоляции указывается, например, так: @Transactional(isolation = Isolation.SERIALIZABLE). Если используемая СУБД или транзакционный менеджер не поддерживает указанный уровень, то будет брошено исключение. Ранее, в чистом JPA, существовало ограничение: стандартный JPA не позволял менять изоляцию “на лету” (только глобально для соединения), но начиная с Spring 4.1 JpaTransactionManager умеет устанавливать уровень изоляции через JDBC-соединение. Таким образом, сегодня вы можете использовать настройку isolation в Spring Boot JPA, и она будет работать, если база данных поддерживает соответствующий уровень.

На практике подавляющее большинство приложений используют READ_COMMITTED или REPEATABLE_READ как баланс между согласованностью данных и производительностью. Уровень SERIALIZABLE выбирается для критичных финансовых операций, требующих абсолютной точности (при этом нужно быть готовым к повторным попыткам транзакции при возникновении конфликтов). Явно указывать уровень изоляции в @Transactional имеет смысл, когда конкретно для данной операции нужны гарантии выше или ниже, чем глобальные настройки базы. Например, отчет может выполняться с SERIALIZABLE, чтобы получить “снимок” данных на текущий момент, а не видеть обновления, которые параллельно вносятся другими транзакциями.

Cводная таблица по уровням изоляции транзакций

Isolation Level	Описание	Разрешенные эффекты конкурентности	Ограниченные эффекты	Особенности / Поведение	Пример использования
DEFAULT	Использует уровень изоляции по умолчанию, заданный в СУБД.	Зависит от настроек базы (обычно READ COMMITTED или REPEATABLE READ).	Зависит от настроек базы.	Не задает уровень явно; полагается на конфигурацию БД. Рекомендуется, если нет особых требований.	99% CRUD-операций в приложении, когда настройки БД подобраны под требования.
READ_UNCOMMITTED	Самый низкий уровень изоляции. Позволяет читать незакоммиченные изменения других транзакций.	Dirty Read, Non-repeatable Read, Phantom Read возможны.	Нет ограничений.	Максимальная параллельность, минимальные блокировки; может приводить к неконсистентным данным.	Мониторинговые запросы, когда точность не критична, а важна скорость.
READ_COMMITTED	Чтение только зафиксированных данных.	Non-repeatable Read, Phantom Read возможны.	Dirty Read невозможен.	Стандартный уровень в Oracle, PostgreSQL, SQL Server; оптимальный баланс консистентности и производительности.	Большинство бизнес-запросов, например, просмотр списка заказов в e-commerce.
REPEATABLE_READ	Гарантирует одинаковые данные при повторном чтении в рамках транзакции.	Phantom Read возможен.	Dirty Read, Non-repeatable Read невозможны.	По умолчанию в MySQL (InnoDB); предотвращает изменение уже прочитанных строк другими транзакциями до конца текущей.	Финансовые операции: расчет суммы по фиксированному набору счетов, который не должен меняться во время транзакции.
SERIALIZABLE	Максимальный уровень изоляции: транзакции выполняются как последовательно.	Нет эффектов конкурентности (Dirty, Non-repeatable, Phantom исключены).	Все эффекты исключены.	Наиболее строгий, но может вызывать падение производительности из-за блокировок и конфликтов; требует повторных запусков транзакций при ошибках.	Критические расчеты: закрытие бухгалтерского периода, перерасчет остатков на складе.

Поведение rollback: когда транзакция откатывается?

После того как транзакция открыта, Spring должен решить – фиксировать ее (commit) или откатывать (rollback) при завершении метода. По умолчанию логика довольно простая: если метод завершился без необработанных исключений, транзакция подтверждается, если же из метода выброшено неперехваченное исключение, транзакция откатывается. Однако важно знать, что не каждое исключение приведет к откату. По умолчанию Spring откатывает транзакцию только при возникновении unchecked exception (исключения, унаследованные от RuntimeException или Error). Проверяемые исключения (наследники Exception, но не RuntimeException) по умолчанию не приводят к откату. Такой дизайн исторически обусловлен тем, что проверяемые исключения часто означают ожидаемые ситуации, которые программист может обработать (например, бизнес-ошибка типа “товар закончился на складе”) – откатывать транзакцию в таких случаях не всегда нужно.

Конечно, эти правила можно изменить. Параметры аннотации @Transactional позволяют настроить поведение при исключениях:

• rollbackFor – список классов исключений (или их имен), при возникновении которых нужно откатить транзакцию, даже если они являются проверяемыми (checked). Например, можно указать @Transactional(rollbackFor = SQLException.class), и тогда транзакция откатится и при выбросе java.sql.SQLException (который является checked-исключением). Также существует псевдоним rollbackForClassName для указания имен исключений строкой.
• noRollbackFor – наоборот, список исключений, при которых не следует откатывать транзакцию. Это позволяет исключить из стандартного поведения какие-то RuntimeException. Например, @Transactional(noRollbackFor = CustomBusinessException.class) означает, что если метод выбросит CustomBusinessException (наследник RuntimeException), Spring не будет откатывать транзакцию – вероятно, такое исключение используется для управления потоком выполнения (например, чтобы прервать операцию, но сохранить уже сделанные изменения).

Проиллюстрируем эти настройки на примерах кода:

// 1. Откат по умолчанию (только RuntimeException)
@Transactional
public void createOrder(Order order) {
    orderRepository.save(order);
    // Если бросить RuntimeException или Error, транзакция откатится.
    // Если бросить, например, IOException (checked exception) - транзакция НЕ откатится по умолчанию.
}

// 2. Явный откат при checked-исключении
@Transactional(rollbackFor = { SQLException.class, IOException.class })
public void importData(File file) throws IOException, SQLException {
    dataService.insertFromFile(file);
    // Если возникнет SQLException или IOException, транзакция откатится благодаря rollbackFor.
    // RuntimeException и так откатят транзакцию.
}

// 3. Не откатывать при специфическом Runtime-исключении
@Transactional(noRollbackFor = { EntityNotFoundException.class })
public User getUserById(Long id) {
    User user = userRepository.findById(id)
        .orElseThrow(() -> new EntityNotFoundException("User not found"));
    // Здесь при выбрасывании EntityNotFoundException транзакция НЕ откатится, 
    // хотя это RuntimeException, потому что указано noRollbackFor.
    return user;
}

Важно понимать, что правила отката срабатывают только если исключение выходит из метода наружу. Если внутри метода вы перехватили исключение и не дали ему всплыть, то для Spring выполнение считается успешным, и он попытается закоммитить транзакцию. Даже если внутри произошло исключение, но вы его поймали – фреймворк об этом “не узнает”. В таких случаях, если вам все же нужен откат, следует вручную пометить транзакцию на rollback. Для этого можно вызвать:

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

Этот программный способ помечает текущую транзакцию как подлежащую откату без выбрасывания исключения. Однако учтите, что такой вызов сработает только внутри транзакционного контекста; если транзакции нет, currentTransactionStatus() вернет статус без транзакции. Как правило, лучше не злоупотреблять этим и позволять исключениям пробрасываться – используя декларативный подход (rollbackFor и т.п.), код получается чище и понятнее.

Также стоит знать, что Spring определяет два специальных исключения, связанных с транзакциями: UnexpectedRollbackException – бросается, когда транзакция была помечена на откат (например, внутренним вызовом), но внешний код об этом не знает и пытается выполнить commit. Второе – TransactionSystemException, которое оборачивает низкоуровневые проблемы системы транзакций (например, сбой при работе с JDBC или JPA во время коммита). В обычной работе с @Transactional вы с ними редко сталкиваетесь, но полезно понимать их природу.

Итак, по умолчанию Spring откатывает транзакцию при RuntimeException, а при checked-исключениях – нет. Вы можете изменить это поведение, явно указав классы исключений для отката или, наоборот, для игнорирования отката. Всегда старайтесь проектировать логику так, чтобы неперехваченное исключение действительно означало необходимость отката – это самый ясный и надежный подход. Ловите исключения внутри транзакции только если уверены, что можете корректно продолжить работу и зафиксировать частичный результат.

Ленивая загрузка (Lazy Loading) и границы транзакции

Одно из распространенных явлений при работе с ORM (например, Hibernate) – это ленивая загрузка связанных данных. Свойства сущностей, отмеченные как LAZY, не загружаются сразу из базы при первом запросе – вместо них Hibernate подставляет прокси-объекты, которые запрашивают реальные данные только когда вы к ним обращаетесь. Однако для выполнения такого дозагружения необходим активный сеанс Hibernate (EntityManager) и открытая транзакция. Если попытаться обратиться к lazy-свойству вне контекста сессии, ORM не сможет выполнить запрос – в результате бросается знаменитое исключение LazyInitializationException с сообщением “no Session” (нет сессии для инициализации прокси).

Аннотация @Transactional напрямую влияет на ленивую загрузку, потому что управление сессией Hibernate привязано к транзакции. Как правило, сессия открывается при старте транзакции и закрывается при ее коммите/откате. Поэтому, пока код выполняется внутри метода с @Transactional, все LAZY-связи можно свободно инициализировать – необходимые данные будут подгружены из базы в рамках той же транзакции. А вот как только метод закончился и транзакция закрылась, прикрепленный к ней EntityManager тоже закрывается. Любая попытка доступа к ленивым полям после этого приведет к LazyInitializationException.

Рассмотрим сценарий: у вас есть метод сервиса, помеченный @Transactional, который загружает сущность и возвращает ее в контроллер для использования на слое представления. Если у сущности есть лениво инициализируемые поля (например, коллекция связанных объектов), и вы попытаетесь обратиться к ним во View (уже за пределами метода сервиса), то получите исключение – транзакция к тому моменту завершена, и сессия закрыта. Часто новички забывают об этом, получая LazyInitializationException, хотя, казалось бы, запрос выполнялся в транзакции.

Есть несколько способов избежать этой проблемы:

• Инициализировать необходимые lazy-поля внутри транзакции. Проще всего – вызвать нужные геттеры внутри метода сервиса (пока транзакция открыта), либо использовать JOIN FETCH в JPQL/HQL-запросе, заранее подгрузив все требуемые данные. Тогда к моменту возврата из метода вся нужная информация уже будет загружена.
• Воспользоваться шаблоном Open Session in View (OSIV). Spring (а точнее Spring Boot) по умолчанию включает механизм, который оставляет сессию Hibernate открытой на время выполнения всего веб-запроса. Это означает, что даже после выхода из сервисного метода (но пока продолжается обработка запроса в контроллере/вью), сессия остается активной, и ленивые поля могут подгрузиться при обращении. В Spring Boot этот механизм включен через свойство spring.jpa.open-in-view=true (стоит по умолчанию). Он помогает начинающим разработчикам сразу не столкнуться с LazyInitializationException. Однако OSIV имеет и обратную сторону: держать сессию открытой длительное время (на весь запрос) может быть не оптимально. Транзакция к тому моменту уже завершена, но сессия все равно привязана к соединению. Это чревато длительным удержанием connection при формировании ответа и потенциально большим количеством дополнительных запросов (N+1) при рендеринге. Многие продвинутые проекты предпочитают отключать OSIV и явно контролировать загрузку данных.
• Не возвращать ленивые сущности наружу. Хороший вариант – преобразовывать сущности в DTO внутри транзакции и возвращать уже полностью заполненные DTO. Либо вообще избегать LAZY-загрузки для данных, которые нужны сразу: можно пометить отношения как EAGER (но это грубое решение, ухудшающее производительность глобально – ведь данные будут загружаться всегда, даже когда они не нужны).

Главный вывод: если получаете LazyInitializationException, значит вы пытаетесь обратиться к данным вне контекста транзакции. Либо расширьте контекст (например, за счет OSIV или переноса логики в сервисный слой), либо загружайте необходимые данные внутри транзакции заранее. Добавление @Transactional к коду, который читает ленивые объекты, часто решает проблему – сессия останется открытой до конца метода, и Hibernate спокойно выполнит дополнительные запросы. Только не переусердствуйте: открывать транзакцию там, где вы просто рендерите данные, не всегда хорошая идея (это может создать длительную транзакцию). Лучше спроектировать уровень доступа к данным так, чтобы к моменту выхода из сервисного метода у вас уже была вся нужная информация.

Например, вместо того чтобы возвращать из транзакционного метода объект User с ленивой коллекцией roles и затем где-то в шаблоне обращаться к user.getRoles(), можно сразу в сервисе вызвать user.getRoles().size() (инициализируя коллекцию) или выполнить запрос с JOIN FETCH, получив пользователя сразу с ролями.

В целом, понимание механизма ленивой загрузки и жизненного цикла сессии Hibernate – обязательная часть работы с Spring Data JPA. Аннотация @Transactional гарантирует наличие активной сессии на время работы метода, поэтому все операции загрузки/сохранения должны выполняться в пределах транзакции.

Сравнение с ручным управлением транзакциями (PlatformTransactionManager)

Мы рассмотрели декларативный подход – когда достаточно повесить @Transactional, и Spring сам разберется, когда начать и завершить транзакцию. Но что стоит за этим “магическим” подходом? А стоит за ним вполне реальный API: интерфейс PlatformTransactionManager и связанные с ним классы.

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

@Autowired
private PlatformTransactionManager txManager;

public void doSomething() {
    // Определяем параметры транзакции (можно задать propagation, timeout, readOnly и др.)
    DefaultTransactionDefinition def = new DefaultTransactionDefinition();
    def.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
    def.setTimeout(5); // таймаут 5 секунд, например
    // Начинаем транзакцию
    TransactionStatus status = txManager.getTransaction(def);
    try {
        // ... выполняем логику, как внутри @Transactional
        // Например:
        repository.save(entity);
        // Если дошли сюда без исключений, фиксируем транзакцию:
        txManager.commit(status);
    } catch (Exception ex) {
        // В случае ошибки откатываем транзакцию:
        txManager.rollback(status);
        throw ex; // пробрасываем дальше
    }
}

Как видим, код вручную вызывает txManager.getTransaction() для старта транзакции и затем явно делает commit или rollback. Аннотация @Transactional избавляет нас от всей этой шаблонной обвязки, позволяя выразить намерение декларативно. Spring AOP фактически оборачивает ваш метод примерно таким же try-catch блоком.

Ручное управление транзакциями может понадобиться, если требуется особенно тонкий контроль. Например, нужно выполнить часть метода без транзакции, затем начать транзакцию, потом снова выполнить что-то без транзакции – такое сложно выразить одной аннотацией. Или вы пишете низкоуровневый код, где нельзя легко применить Spring AOP (например, внутри нестандартного фонового потока). В таких случаях можно воспользоваться PlatformTransactionManager напрямую или через удобный шаблон TransactionTemplate – Spring предоставляет этот класс, позволяющий выполнить лямбда-выражение внутри транзакции, что упрощает синтаксис программного управления транзакциями.

Тем не менее, в 99% случаев лучше использовать @Transactional, так как это существенно уменьшает объем шаблонного кода и вероятность ошибок. Spring сам правильно обработает все исключения, позаботится о выбросе UnexpectedRollbackException в нужных ситуациях, и код будет выглядеть чище. Программные транзакции стоит рассматривать только при наличии веских причин. Например, одна из таких причин – оптимизация длительных операций: допустим, внутри одной бизнес-операции вы делаете и запросы в базу, и длительный вызов внешнего веб-сервиса. Держать транзакцию открытой на все время внешнего вызова не хочется (это блокирует соединение с БД). Можно разделить логику: обернуть операции с базой в две транзакции (до и после внешнего вызова), а сам внешний вызов выполнить вне транзакции. Реализовать это можно, например, вынеся внешний вызов в отдельный метод с PROPAGATION_REQUIRES_NEW (при этом внешнюю транзакцию пометив как NOT_SUPPORTED), либо более явно, используя программное управление. В любом случае, такие ситуации – скорее исключение.

PlatformTransactionManager в Spring имеет несколько реализаций: для работы с одной БД через JDBC (DataSourceTransactionManager), для JPA (JpaTransactionManager), для распределенных транзакций JTA (JtaTransactionManager) и другие. В контексте Spring Boot + Spring Data JPA обычно используется JpaTransactionManager, который под капотом все равно работает с JDBC-соединениями. Поэтому все, что мы обсуждали (propagation, изоляция, откаты), справедливо и для Hibernate/JPA – Spring просто вызывает необходимые методы у EntityManager и Connection.

Подведем итог: @Transactional – это надстройка над PlatformTransactionManager + AOP. Ручное управление транзакциями возможно и понимать его полезно (приведенный выше шаблон try/commit/rollback – по сути то, что делает Spring за нас). Но в ежедневной работе гораздо удобнее и безопаснее пользоваться декларативными транзакциями.

Типичные ошибки и анти-паттерны при использовании @Transactional

Несмотря на простоту использования аннотации @Transactional, при ее применении есть ряд подводных камней. Рассмотрим самые распространенные ошибки, которые совершают разработчики (особенно новички):

• Аннотация на приватных или protected методах. Как упоминалось ранее, Spring обрабатывает @Transactional через прокси, которые по умолчанию оборачивают только публичные методы. Если пометить private-метод класса аннотацией, Spring не сможет перехватить его вызов – в итоге никакой транзакции не будет, и вы об этом даже не узнаете (Spring не выдаст ошибку, он просто проигнорирует аннотацию). Аналогично для методов с областью видимости package-private (по умолчанию) и protected – они тоже не подпадают под действие прокси. Анти-паттерн: помечать не-публичные методы транзакционными. Решение: делать транзакционными только публичные методы сервисов. Вспомогательные методы, которые не предназначены для вызова извне, либо вызывать внутри транзакционного метода, либо вынести в другой бин/сервис, вызов которого будет обернут транзакцией.
• Вызов собственного транзакционного метода из другого метода того же класса. Этот сценарий называется self-invocation и тоже уже обсуждался. Проблема в том, что вызов происходит напрямую, минуя транзакционный прокси, поэтому аннотация не срабатывает. Например, у вас в классе UserService есть метод createUser() с @Transactional, и он внутри вызывает метод validateUser() того же класса, тоже помеченный @Transactional. При вызове this.validateUser() транзакция не начнется, даже если вы рассчитывали на обратное. В результате validateUser() выполнится без транзакции. Это может привести к тонким багам, особенно когда логика метода меняется, и вы полагаетесь на наличие транзакции. Решение: не вызывать через this свои же транзакционные методы. Если нужно структурировать логику – вынесите второй метод в другой бин (например, UserValidatorService), и вызывайте его через Spring (через @Autowired), тогда его @Transactional вступит в силу. Либо вызывать внутренние методы без @Transactional, если они и так выполняются внутри транзакции вызывающего метода. В крайнем случае, можно программно получить ссылку на свой бин через Application Context (context.getBean(UserService.class).validateUser()) – тогда вызов пойдет через прокси, но такой подход считается некрасивым и усложняет код.
• Потеря прокси при создании объектов вручную. Бывают случаи, когда бин передается куда-то не в виде прокси, а самим объектом this. Например, вы вручную создали экземпляр класса (вне Spring-контейнера) или передали this в статический контекст. Тогда @Transactional на таком объекте не сработает, потому что Spring не управляет им. Правильный подход: всегда получать бины через Spring DI-контейнер. Если нужно внутри класса вызвать собственный сервис с транзакцией – внедрите его через @Autowired вместо создания через new. Убедитесь, что обращаетесь именно к бину-прокси (обычно Spring сам позаботится об этом при внедрении зависимостей). Этот момент часто всплывает при написании тестов: если вы вручную создаете сервис new UserService() и вызываете его метод с @Transactional, транзакция не начнется. Нужно либо поднимать Spring-контекст в тесте, либо использовать аннотации Spring Test (например, @RunWith(SpringRunner.class)) – чтобы Spring сам создал бин и применил к нему транзакционный прокси.
• Неактивированное управление транзакциями (забыли включить @EnableTransactionManagement). В Spring Boot такое бывает редко, поскольку автоконфигурация включает поддержку транзакций автоматически (при наличии нужных зависимостей). Но в обычном Spring-проекте можно пометить метод @Transactional и обнаружить, что транзакция не открывается. Причина – забыли добавить @EnableTransactionManagement (в Java-конфигурации) или <tx:annotation-driven/> в XML. В итоге аннотация просто игнорируется, так как не настроен процессор транзакций. Решение: убедиться, что конфигурация управления транзакциями подключена. В Boot-дополнительно проверить, что зависимость spring-tx присутствует (обычно она транзитивно подтягивается).
• Неправильный выбор слоя для транзакции. Иногда @Transactional ставят на методы контроллера (Web-слой) или даже на класс контроллера. Это не критично, но чаще всего неоптимально: лучше отделять транзакционную логику на уровне сервисов. Контроллер может вызывать несколько сервисов – оборачивать весь запрос в транзакцию может быть слишком долго (например, если запрос генерирует большой HTML, незачем держать транзакцию открытой во время рендеринга страницы). Кроме того, если на контроллере висит транзакция и он вызывает несколько сервисов, то все они выполняются в одной транзакции – возможно, это не то, что нужно (например, один сервис мог бы откатиться независимо, не затронув другие). Best practice: открывать транзакции на уровне сервисов, а не контроллеров или репозиториев. (Методы репозиториев Spring Data JPA по умолчанию тоже транзакционные, но они охватывают лишь выполнение самого запроса; для комплексной бизнес-операции лучше контролировать транзакцию на уровне сервиса.)
• Долгие операции внутри транзакции. Это неочевидная, но серьезная проблема. Транзакция должна быть как можно короче по времени. Когда транзакция открыта, она удерживает определенные блокировки в базе, а также занимает соединение из пула. Если внутри транзакции выполнять долгие задачи (вызов внешнего сервиса, ожидание ответа по сети, тяжелые вычисления), то все это время транзакция остается открытой. Это может привести к блокировке других параллельных транзакций и к исчерпанию свободных соединений. Мы уже приводили пример: метод помечен @Transactional, внутри делается внешний API-вызов, который подвисает – при наплыве таких одновременных вызовов можно быстро остаться без свободных коннекшенов к базе. Решение: выносите нетранзакционную деятельность за пределы транзакции. Например, сначала вне транзакции вызовите внешний сервис, затем откройте транзакцию и сохраните результаты (или наоборот: сначала в транзакции подготовьте данные и сохраните их, завершите транзакцию, а потом вызовите внешний сервис и, если нужно, в отдельной транзакции зафиксируйте ответ). Если полностью разделить не получается, рассмотрите вариант снизить уровень изоляции, чтобы уменьшить блокировки, или увеличить таймаут транзакции – но эти меры частичные. Общий принцип: минимизируйте время жизни транзакции.
• Чрезмерное использование REQUIRES_NEW. Как уже говорилось, не стоит без необходимости применять Propagation.REQUIRES_NEW в большом количестве мест – это чревато проблемами с ресурсами и непредсказуемым поведением. Например, если разработчик решит пометить каждый метод репозитория как REQUIRES_NEW “про запас”, то любой вызов репозитория будет запускать свою транзакцию и сразу коммититься отдельно от общей транзакции сервиса. Это, во-первых, нарушает целостность бизнес-операции, а во-вторых, может приводить к неправильному состоянию данных (сервис может выбросить исключение, но часть изменений уже будет зафиксирована). REQUIRES_NEW следует использовать осознанно, только для действительно независимых операций (как в примере с аудитом/логированием).
• Игнорирование исключений из транзакционного метода. Иногда можно увидеть код: try { service.doTransactionalWork(); } catch (Exception e) { // просто логируем ошибку, не пробрасываем дальше } Здесь вызываемый doTransactionalWork() помечен @Transactional. Если внутри него произошла RuntimeException, Spring откатит транзакцию, но, поймав исключение и не пробросив его выше, вы потеряете информацию об ошибке. Более того, внешний код (после блока try-catch) будет думать, что все прошло успешно (ведь исключение подавлено). Это может привести к нарушению логики: транзакция откатилась, данных в базе нет, а выполнение программы пошло дальше как ни в чем не бывало. Совет: не глушите исключения, которые сигнализируют о сбое транзакции. Если уж ловите их, то после логирования как минимум бросьте новое unchecked-исключение или иным способом пометьте операцию как неуспешную. Либо изначально используйте проверяемые исключения для ожидаемых ситуаций (но помните про их влияние на rollback).
• Многопоточность и транзакции. Если вы вручную запускаете новые потоки или асинхронные задачи внутри транзакционного метода, помните: транзакция не распространяется на другие потоки. Spring связывает транзакцию с текущим потоком (обычно через ThreadLocal). Поэтому новый поток начнется без транзакции. В некоторых случаях это нормально (например, вы сознательно выносите часть работы в фон без транзакции), но нередко разработчики ошибочно полагают, что фоновые задачи продолжат выполняться в той же транзакции – это не так. Решение – либо явно передавать контекст транзакции в новый поток (сложно и редко нужно), либо (проще) не выполнять параллельных изменений данных внутри одной логической операции. Если требуется параллелизм, каждую задачу выполняйте с своей транзакцией или синхронизируйте их.

Конечно, этот список не исчерпывающий, но он покрывает самые частые проблемы. Большинство из них решаются пониманием того, как именно Spring управляет транзакциями через прокси и где проходят границы транзакционных контекстов.

Советы по отладке и логированию транзакций

Отлаживать проблемы с транзакциями бывает непросто, так как многое происходит “за кадром”. К счастью, Spring предоставляет возможности для логирования транзакционной активности. Если вы подозреваете, что транзакция не открывается или откатывается не так, как нужно, включите логирование для категории org.springframework.transaction на уровень TRACE. Это самый подробный уровень, при котором в логах появятся сообщения о создании, подтверждении или откате транзакций, о присоединении к существующим транзакциям, об установке флагов вроде read-only, и т.д.

Например, при включенном TRACE вы сможете увидеть в логах строки вида: “Creating new transaction with name [com.example.MyService.method]: PROPAGATION_REQUIRED, isolation: DEFAULT”, “Initiating transaction commit”, “Rolling back transaction because of exception” и т.п. Эти сообщения очень полезны, чтобы понять, вошел ли метод в транзакцию и что с ней произошло. Также логирование покажет, не случилось ли неожиданного отката: если внутренняя ошибка пометила транзакцию как rollback-only, а внешняя попыталась закоммитить, вы увидите в логах сообщение об UnexpectedRollbackException.

Помимо Spring-логов, можно задействовать и логи SQL-уровня – например, включить вывод выполняемых SQL-запросов и событий commit/rollback на уровне JDBC. В Hibernate для этого есть параметр hibernate.show_sql или, более тонко, можно включить логгер org.hibernate.SQL (для запросов) и org.hibernate.resource.transaction (для транзакционных событий). Пул соединений (например, HikariCP) тоже может логировать выдачу и возврат коннекшенов – это косвенно помогает понять, когда транзакция берет соединение и когда возвращает (при коммите/откате соединение обычно освобождается в пул). Однако чаще всего достаточно именно Spring-логов на уровне TRACE, чтобы отследить жизненный цикл транзакции.

Еще один совет: если транзакция ведет себя не так, как ожидается, убедитесь, что метод действительно вызывается через Spring-прокси. В отладчике можно посмотреть реальный класс вашего бина – если видите что-то вроде com.example.MyService$$EnhancerBySpringCGLIB$$..., значит прокси создан и транзакция должна работать. Если же тип объекта в runtime – ровно ваш класс (без суффиксов $$), вероятно, вы обошли контейнер Spring (например, вызвали new MyService() напрямую). В таком случае никаких транзакций не будет.

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

Наконец, для тестирования транзакционного поведения Spring предоставляет удобный механизм в модуле spring-test: аннотация @Transactional на класс или метод теста. Если пометить тест как транзакционный, Spring автоматически откроет транзакцию перед началом и откатит ее после завершения теста, чтобы не оставлять следов в базе. Это удобно для интеграционных тестов репозиториев и сервисов. Но имейте в виду: внутри такого теста все операции проходят в рамках одной транзакции, и если ваш код зависит от реального коммита (например, срабатывание триггеров в БД или видимость данных из другого соединения), то вы не увидите этого эффекта до окончания теста (то есть до отката транзакции). В таких случаях можно либо отключить транзакционность в тесте, либо вручную вызывать flush()/commit внутри тестового метода, когда это необходимо.

Заключение

Аннотация @Transactional – мощный инструмент, существенно упрощающий работу с транзакциями в Spring-приложениях. Каждый Java-разработчик, особенно работающий с Spring Boot и JPA/Hibernate, должен понимать, как она работает под капотом и какие возможности предоставляет. Подведем основные итоги и рекомендации:

• Используйте @Transactional осознанно. Помечайте транзакцией только те операции, которые действительно требуют атомарности и целостности. Чаще всего это бизнес-методы сервисного слоя, выполняющие несколько действий с данными. Нет смысла открывать транзакцию ради одного простого чтения – это лишняя нагрузка (впрочем, Spring Data JPA все равно выполняет методы репозитория чтения в короткой read-only транзакции по умолчанию, но это деталь реализации).
• Знайте propagation-транзакций. По умолчанию REQUIRED подходит в большинстве случаев. Но если сценарий требует независимых операций – используйте REQUIRES_NEW (и не забудьте про дополнительные ресурсы под новые соединения). Если нужна частичная откатимость – изучите NESTED и убедитесь, что ваша конфигурация его поддерживает (например, вы не используете JTA). Другие режимы (MANDATORY, NEVER, SUPPORTS, NOT_SUPPORTED) применяются в специфических ситуациях – используйте их, чтобы явно задать контракт метода относительно транзакции.
• Контролируйте уровень изоляции при необходимости. Большинство систем обходятся дефолтным уровнем изоляции базы данных. Но если у вас высокие требования к консистентности – не бойтесь выставить Isolation.SERIALIZABLE на критичных участках (главное, протестируйте нагрузку, так как это может снизить производительность). И наоборот, если операций записи мало, а читающих запросов много, можно оставаться на READ COMMITTED для лучшей параллельности. Помните: уровень изоляции – компромисс между консистентностью и производительностью.
• Учитывайте поведение rollback. Знайте, что RuntimeException по умолчанию откатывает транзакцию, а checked-исключение – нет. Проектируя свою систему исключений, продумайте, какие ситуации должны приводить к откату. Возможно, ваши бизнес-исключения имеет смысл сделать непроверяемыми. Если нет – используйте параметр rollbackFor. И наоборот, если определенные Runtime-исключения не должны откатывать транзакцию, воспользуйтесь noRollbackFor (редкий случай, но знать стоит).
• Следите за LazyInitializationException. Это явный индикатор, что вы вышли за границы транзакции, пытаясь лениво загрузить данные. Решение – либо расширить границы (включить OSIV, хотя это спорно), либо загружать данные заранее внутри транзакции. Помните: при закрытии транзакции Hibernate-сессия закрывается, и дальнейшие обращения к объектам уже не попадут в базу.
• Не забывайте об ограничениях прокси. Не помечайте приватные методы @Transactional, избегайте внутренних self-вызовов транзакционных методов. При необходимости рефакторьте код – вынесите такие методы в отдельные бины или делайте их внутренними вызовами без аннотации. Эти ограничения часто становятся причиной “неработающих” транзакций.
• Транзакция != весь веб-запрос. Держите транзакцию только на время, пока реально идет работа с базой. Обычно это быстрые операции чтения/записи. Не выполняйте долгих пауз (ожидание ввода пользователя, внешние HTTP-запросы) внутри транзакции.
• Логируйте и анализируйте транзакции при проблемах. Включение TRACE-логирования Spring поможет разобраться, что происходит с транзакциями. Можно увидеть, какие propagation используются, нет ли конфликтов настроек (например, внутренний readOnly vs внешний read-write – по умолчанию Spring их не проверяет, но для отладки можно включить validateExistingTransactions=true, тогда конфликт настроек сразу бросит исключение).
• Придерживайтесь принципа единой ответственности транзакции. Один метод – одна логическая транзакция. Не пытайтесь смешивать несколько разнородных операций в одной транзакции “про запас”. Лучше разделить их на несколько методов/транзакций и при необходимости управлять ими явно (например, с помощью requires_new или вручную).

В экосистеме Spring Data JPA транзакции – неотъемлемая часть работы. Благодаря @Transactional разработчики могут писать менее многословный и более понятный код, сфокусированный на бизнес-логике, а не на рутине управления транзакциями. Понимая рассмотренные выше темы – от механизма прокси до уровней изоляции и propagation, – вы вооружены знаниями для создания надежных, корректных и эффективных в работе с данными приложений.

Управление транзакциями в Spring действительно становится простым, но только когда вы знаете о нем достаточно и не совершаете типичных ошибок. Данная статья представила детальное погружение в нюансы @Transactional – применяйте эти знания на практике, и ваши приложения будут работать корректно и предсказуемо даже в самых сложных сценариях.