Spring transactional не работает

Spring @Transactional — ошибки, которые совершали все

Вероятно, одной из наиболее часто используемых аннотаций Spring является @Transactional . Несмотря на ее популярность, иногда она используется неправильно, в результате чего получается не совсем то, что задумал инженер-программист.

В этой статье я собрал проблемы, с которыми лично сталкивался в проектах. Надеюсь, этот список поможет вам лучше понять транзакции и поспособствует устранению нескольких ваших замечаний.

1. Вызовы в пределах одного класса

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

Аннотация не работает в методе registerAccount:

В этом случае при вызове registerAccount() сохранение пользователя и создание команды не будут выполняться в одной транзакции. @Transactional работает на основе аспектно-ориентированного программирования. Поэтому обработка происходит, когда один бин вызывается из другого. В приведенном выше примере метод вызывается из того же класса, поэтому прокси не могут быть применены. Так происходит и с другими аннотациями, как, к примеру, @Cacheable.

Проблема может быть решена тремя основными способами:

Самостоятельная инъекция (Self-inject)

Создать еще один уровень абстракции

Использовать TransactionTemplate в методе registerAccount() , обернув вызов createAccount()

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

Аннотация работает в методе registerAccount:

2. Обработка не всех исключений

По умолчанию откат происходит только при RuntimeException и Error. В то же время в коде могут встречаться проверяемые исключения, при которых также необходимо откатить транзакцию.

Установите rollbackFor , если вам нужно откатиться назад в случае StripeException:

3. Уровни изоляции транзакций и распространение

Часто разработчики добавляют аннотации, не задумываясь о том, какого поведения они хотят добиться. Почти всегда по умолчанию используется уровень изоляции READ_COMMITED .

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

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

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

4. Транзакции не блокируют данные

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

Однако проблема в том, что ничто не мешает другому экземпляру приложения вызвать findAllByStatus одновременно с первым. В результате метод вернет одни и те же данные в обоих экземплярах, и их обработка будет произведена 2 раза.

Есть 2 способа избежать этой проблемы.

Выбрать для обновления (пессимистическая блокировка)

Select-for-update в PostgreSQL:

В приведенном выше примере, когда выполняется выбор, строки блокируются до конца обновления. Запрос возвращает все измененные строки.

Версионирование сущностей (оптимистическая блокировка)

Этот способ помогает избежать блокировки. Идея заключается в том, чтобы добавить столбец version к нашим сущностям. Таким образом, мы можем выбрать данные и затем обновить их только в том случае, если версия сущностей в базе данных совпадает с версией в приложении. В случае использования JPA можно применить аннотацию @Version .

5. Два разных источника данных

Например, мы создали новую версию хранилища данных, но все еще должны некоторое время поддерживать старую.

Конечно, в этом случае только один save будет обрабатываться транзакционно, именно в том TransactionalManager, который используется по умолчанию.

Spring предоставляет здесь два варианта.

ChainedTransactionManager

ChainedTransactionManager — это способ объявления нескольких источников данных, в которых, в случае исключения, откат будет происходить в обратном порядке. Таким образом, при наличии трех источников данных, если во время фиксации на втором произошла ошибка, то откат будет произведен только для первых двух. Третий уже зафиксировал изменения.

JtaTransactionManager

Этот менеджер позволяет использовать полностью поддерживаемые распределенные транзакции на основе двухфазной фиксации. Однако он делегирует управление бэкенд-провайдеру JTA. Это могут быть серверы Java EE или отдельные решения (Atomikos, Bitrionix и т.д.).

Заключение

Транзакции — непростая тема, и нередко возникают проблемы с их пониманием. Чаще всего они не полностью покрываются тестами, так что большинство ошибок можно заметить только при ревью кода. А если в продакшне случаются инциденты, найти первопричину всегда непросто.

Материал подготовлен нашим экспертом — Александром Коженковым и опубликован в преддверии старта курса «Highload Architect».

Всех желающих приглашаем на открытый урок «Репликация». На занятии мы:
— Рассмотрим принцип работы механизмов репликации с точки зрения синхронизации данных;
— Проанализируем проблемы асинхронной репликации и варианты их решения;
— Обсудим предназначение и потенциальные проблемы репликации вида master-master, а также рассмотрим преимущества и недостатки безмастерной репликации.

Источник

Spring @Transactional — ошибки, которые совершали все

Вероятно, одной из наиболее часто используемых аннотаций Spring является @Transactional . Несмотря на ее популярность, иногда она используется неправильно, в результате чего получается не совсем то, что задумал инженер-программист.

В этой статье я собрал проблемы, с которыми лично сталкивался в проектах. Надеюсь, этот список поможет вам лучше понять транзакции и поспособствует устранению нескольких ваших замечаний.

1. Вызовы в пределах одного класса

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

Аннотация не работает в методе registerAccount:

В этом случае при вызове registerAccount() сохранение пользователя и создание команды не будут выполняться в одной транзакции. @Transactional работает на основе аспектно-ориентированного программирования. Поэтому обработка происходит, когда один бин вызывается из другого. В приведенном выше примере метод вызывается из того же класса, поэтому прокси не могут быть применены. Так происходит и с другими аннотациями, как, к примеру, @Cacheable.

Проблема может быть решена тремя основными способами:

1. Самостоятельная инъекция (Self-inject)
2. Создать еще один уровень абстракции
3. Использовать TransactionTemplate в методе registerAccount() , обернув вызов createAccount()

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

Аннотация работает в методе registerAccount:

Если вы используете Lombok, не забудьте добавить @Lazy в ваш lombok.config.

2. Обработка не всех исключений

По умолчанию откат происходит только при RuntimeException и Error. В то же время в коде могут встречаться проверяемые исключения, при которых также необходимо откатить транзакцию.

Установите rollbackFor , если вам нужно откатиться назад в случае StripeException:

3. Уровни изоляции транзакций и распространение

Часто разработчики добавляют аннотации, не задумываясь о том, какого поведения они хотят добиться. Почти всегда по умолчанию используется уровень изоляции READ_COMMITED .

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

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

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

4. Транзакции не блокируют данные

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

Однако проблема в том, что ничто не мешает другому экземпляру приложения вызвать findAllByStatus одновременно с первым. В результате метод вернет одни и те же данные в обоих экземплярах, и их обработка будет произведена 2 раза.

Есть 2 способа избежать этой проблемы.

Выбрать для обновления (пессимистическая блокировка)

Select-for-update в PostgreSQL:

В приведенном выше примере, когда выполняется выбор, строки блокируются до конца обновления. Запрос возвращает все измененные строки.

Версионирование сущностей (оптимистическая блокировка)

Этот способ помогает избежать блокировки. Идея заключается в том, чтобы добавить столбец version к нашим сущностям. Таким образом, мы можем выбрать данные и затем обновить их только в том случае, если версия сущностей в базе данных совпадает с версией в приложении. В случае использования JPA можно применить аннотацию @Version .

5. Два разных источника данных

Например, мы создали новую версию хранилища данных, но все еще должны некоторое время поддерживать старую.

Конечно, в этом случае только один save будет обрабатываться транзакционно, именно в том TransactionalManager, который используется по умолчанию.

Spring предоставляет здесь два варианта.

ChainedTransactionManager — это способ объявления нескольких источников данных, в которых, в случае исключения, откат будет происходить в обратном порядке. Таким образом, при наличии трех источников данных, если во время фиксации на втором произошла ошибка, то откат будет произведен только для первых двух. Третий уже зафиксировал изменения.

Этот менеджер позволяет использовать полностью поддерживаемые распределенные транзакции на основе двухфазной фиксации. Однако он делегирует управление бэкенд-провайдеру JTA. Это могут быть серверы Java EE или отдельные решения (Atomikos, Bitrionix и т.д.).

Заключение

Транзакции — непростая тема, и нередко возникают проблемы с их пониманием. Чаще всего они не полностью покрываются тестами, так что большинство ошибок можно заметить только при ревью кода. А если в продакшне случаются инциденты, найти первопричину всегда непросто.

Источник

@Transactional в Spring под капотом

В этой статье рассматривается как работает аннотация @Transactional в Spring под капотом. При этом в основном рассматривается НЕ реактивный стек. Статья рассматривает код Spring 5.3 и Spring Boot 2.4

Оглавление

Где лежит @Transactional и как его добавить в проект?

Аннотация @Transactional находится в пакете org.springframework.transaction.annotation , т.е. ее полное имя org.springframework.transaction.annotation.Transactional и является частью Spring Framework с версии 1.2. Не путайте с javax.transaction.Transactional . Собственная аннотация Spring предоставляет более расширенные возможности настройки, которые рассматриваются дальше. Аннотацию javax.transaction.Transactional Spring также поддерживает, но лучше их не смешивать и, если создаете приложение на Spring, использовать родные аннотации.

Для того, чтобы добавить в проект пакет, требуется прописать зависимость:

Но с приходом Spring Boot так делать уже не требуется — этот пакет добавлен во все требуемые starter-ы как транзитивная зависимость и, когда вы добавляете, например, spring-boot-starter-data-jpa, то spring-tx подтягивается автоматически через spring-data-jpa

Кто создает инфраструктуру для обработки @Transactional?

В те темные времена, когда еще не было Spring Boot, чтобы включить поддержку @Transactional мы добавляли над конфигурацией аннотацию @EnableTransactionManager , которая является также частью пакета org.springframework.transaction.annotation .

Эта аннотация имеет следующие настройки:

proxyTargetClass (по умолчанию, false) — будет ли прокси создаваться через CGLIB (true) или через interface-based proxies (false). Обратите внимание, что, если поставить true, ВСЕ объекты Spring (beans) будут создаваться через CGLIB, не только те, что помечены @Transactional

mode (по умолчанию AdviceMode.PROXY ) — как будут применены Advise. Возможные варианты — AdviceMode.PROXY или AdviceMode.ASPECTJ . Если выбрать AspectJ и корректно его настроить, то при компиляции будет сгенерирован код так, что тело метода будет уже обернуто кодом, управляющим транзакцией. Если выбран AdviceMode.PROXY , то будет использован стандартный механизм создания proxy объектов. (пример с AspectJ)

order — указывает, когда будет применен advice. По умолчанию, LOWEST_PRECEDENCE — т.е. он будет вызван последним в цепочке advice. Это может быть важно, когда вы добавляете собственные advice, в которых есть работа с базой данных

Что же эта аннотация делает? Посмотрим на нее:

Она содержит селектор TransactionManagementConfigurationSelector , работа которого будет рассмотрена дальше.

С приходом Spring Boot необходимость в аннотации @EnableTransactionManager отпала. Теперь это перешло в ответственность Spring Boot. Как же он это делает?

Когда вы добавляете в проект зависимость spring-boot-starter-что-то, то подтягивается транзитивная зависимость — spring-boot-autoconfigure, который содержит в файле spring.factories список авто-конфигураций. Как это работает — можно посмотреть SpingBoot-потрошитель от Борисова. В этом файле есть упоминание конфигурации

которая будет загружена при подъеме контекста. Полный текст для удобства приведен ниже.

Как работают авто-конфигурации хорошо объяснено в «SpringBoot-потрошитель», здесь упомяну только наиболее интересные моменты.

Данная авто-конфигурация будет работать только, если в classpath есть класс PlatformTransactionManager , о работе которого будет написано дальше. Здесь же создается TransactionalOperator, используемый в реактивном стеке.

Наиболее важной частью является статический класс EnableTransactionManagementConfiguration

Он содержит два подкласса, отличаются они только настройкой

Если spring.aop.proxy-target-class = true , то применяется аннотация @EnableTransactionManagement(proxyTargetClass = true)

Если spring.aop.proxy-target-class = false , то применяется аннотация EnableTransactionManagement(proxyTargetClass = false)

Обратите внимание, что по умолчанию для всех современных spring-boot проектов

Поэтому будет использован механизм CGLIB для создания proxy. (Советую посмотреть интервью, где Борисов рассказывает про это изменение поведения Spring Boot).

Кто обрабатывает @Transactional?

В этой части рассмотрим, какая инфраструктура создается для обработки .

В прошлой части мы закончили на

Посмотрим, что происходит дальше.

Здесь используется аннотация @Import. Она обычно используется для обработки следующих трех типов компонентов (component): @Configuration , ImportSelector , ImportBeanDefinitionRegistrar .

TransactionManagementConfigurationSelector , который здесь загружается, принадлежит к ImportSelector . При загрузке контекста он, основываясь на настройках EnableTransactionManagement , определяет какие классы будут подгружаться дальше. Ниже приведен часть кода TransactionManagementConfigurationSelector TransactionManagementConfigurationSelector.

Здесь используются следующие классы для конфигураций:

AutoProxyRegistrar — класс для регистрации средств создания бинов, ProxyTransactionManagementConfiguration — класс для настройки ProxyTransactionManagement .

Посмотрим, что внутри ProxyTransactionManagementConfiguration . (Для удобство код приведен ниже. Хотя форматирование его сильно побило)

Первым создается bean transactionAttributeSource из класса AnnotationTransactionAttributeSource . Он реализует интерфейс TransactionAttributeSource.

Этот bean применяется для проверки: используется ли где-то @Transactional и для получения метаданных (например, propagation) для аннотированных методов или классов.

Дальше создается TransactionInterceptor , внутри которого и будет происходить магия транзакции, которая рассматривается дальше.

И наконец BeanFactoryTransactionAttributeSourceAdvisor , внутри которого помещается TransactionInterceptor .

BeanFactoryTransactionAttributeSourceAdvisor — это обычный PointcutAdvisor (который объединил в одну сущность advisor and pointcut. Пример использования можно посмотреть здесь или здесь, или в видео «Spring patterns для взрослых».

Если вкратце описать принцип их действия, то pointcut определяет, какие классы и методы в них будут проксированы, а advice — какой код будет выполняться.

В нашем случае в конце концов в качестве pointcut будет использован TransactionAttributeSource , а в качестве advice — TransactionInterceptor .

Возникает вопрос — а где всеми любимый BeanPostProcessor , про которые нам так часто все говорили?

Здесь на себя всю работу берет InfrastructureAdvisorAutoProxyCreator , который как раз и является BeanPostProcessor .

Иерархия наследования для класса InfrastructureAdvisorAutoProxyCreator

Обработка @Transactional выполняется по обычным правилам Spring и никакой особой магии здесь нет. Примерная схема работы (взята из официальной документации)

Примерная схема работы @Transactional

Кратко о том как работает proxy или самый популярный вопрос на собеседовании

Во многих фирмах, где проходил собеседование задавали следующий вопрос:

Будет ли при вызове test2 из метода test1 создана новая транзакция?

Самый грамотный и полный ответ, который я встречал, был уже приведен в этой статье на habr. В этой же статье рассмотрим только классический и самый простой случай для лучшего понимания, что происходит дальше.

Под капотом наш bean будет иметь примерно следующий вид

Это прекрасно иллюстрирует этот рисунок

взято с https://www.javainuse.com/spring/spring-boot-aop

И отсюда следует, что при вызове метода test1 код, управляющий транзакциями, вызван не будет и новая транзакция не откроется. Аналогичное поведение — когда вызывается метод родительского класса (реальный случай в одном из проектов).

Как обрабатываются @Transactional

Прежде чем перейти к рассмотрению порядка обработки, давайте посмотрим, какие настройки предоставляет нам эта аннотация. Здесь рассмотрена только часть из них. Остальные можно посмотреть в этой статье на habr или в документации

Наиболее интересные настройка @Transactional

propagation — способ «распространения» транзакций

Выделяется следующие способы:

MANDATORY — если есть текущая активная транзакция — выполняется в ней, иначе выбрасывается исключение

NESTED — выполняется внутри вложенной транзакции, если есть активная, если нет активной — то аналогично REQUIRED

NEVER — выполняется вне транзакции, если есть активная — выбрасывается исключение

NOT_SUPPORTED — выполняется вне транзакции — если есть активная, она приостанавливается

REQUIRED — (значение по умолчанию) — если есть активная, то выполняется в ней, если нет, то создается новая транзакция

REQUIRES_NEW — всегда создается новая транзакция, если есть активная — то она приостанавливается

SUPPORTS — если есть активная — то выполняется в ней, если нет — то выполняется не транзакционно

Правила управления откатом

noRollbackFor и noRollbackForClassName — определяет исключения, при которых транзакция НЕ будет откатана

rollbackFor и rollbackForClassName — определяет исключения, при которых транзакция БУДЕТ откатана

Перед тем как перейти к TransactionInterceptor , давайте вспомним, как мы работали с транзакциями до Spring.

Порядок работы такой:

создаем соединение — DriverManager.getConnection(. )

выполняем необходимые запросы

если не было ошибок — выполняем commit (connection.commit())

Если все-таки была ошибка — откатываем изменения

Вернемся к TransactionInterceptor . Основным методом является — invoke , который делегирует работу родительскому методу invokeWithinTransaction класса TransactionalAspectSupport

Сокращенный код приведен ниже

Если посмотреть внимательно, то этот код повторяет предыдущую логику. Ничего нового:

получаем соединение/транзакцию — createTransactionIfNecessary

выполняем необходимые запросы — invocation.proceedWithInvocation

если не было ошибок — выполняем commitTransactionAfterReturning

Если все-таки была ошибка — откатываем изменения — completeTransactionAfterThrowing

Рассмотрим внимательно каждую часть.

Из важных частей здесь можно отметить только вызов transactionalManager.getTransaction(. ) (работа с TransactionalManager будет описана позже) и вызов prepareTransactionInfo , в котором выполняется txInfo.bindToThread() ; этот метод устанавливает TransactionInfo в ThreadLocal переменную transactionInfoHolder , из которой теперь всегда можно получить статус транзакции через статический метод currentTransactionStatus

Управление откатом изменений

Если транзакция активна, то проверяем, надо ли ее откатывать при этой ошибке, если не надо, то выполняем фиксацию транзакции commit(txInfo.getTransactionStatus()) Проверка исключений выполняется в txInfo.transactionAttribute.rollbackOn(ex) . Выигрывает наиболее близкое по иерархии исключений требование.

Просто выполняется фиксация, если транзакция активна.

TransactionManager — что это такое?

На данный момент TransactionManager , маркировочный интерфейс, не содержащий никаких методов. Его наследуют ReactiveTransactionManager и PlatformTransactionManager

Рассмотрим внимательней последний.

Интерфейс содержит всего 3 метода — создание транзакции, commit и rollback.

Spring предоставляет абстрактный класс AbstractPlatformTransactionManager , который реализовывает требования по propagation . Наследники этого класса по разному реализуют его абстрактные методы, так как это довольно сильно зависит от используемой технологии.

Стоит отметить, что в своей работе AbstractPlatformTransactionManager и его подклассы активно используют org. springframework.transaction.support.TransactionSynchronizationManage для синхронизации и хранения метаинформации, включая connection. Хранение информации осуществляется в наборе статических ThreadLocal переменных.

Как выводить логи транзакций?

Spring выполняет логирование практически всех действий с транзакциями: для этого надо включить уровень логирования DEBUG для пакета org.springframework.transaction , и если используете hibernate, — org.hibernate.transaction

Также можно узнать, что происходит с транзакциями программно, обращаясь к ThreadLocal переменным, которые мы рассмотрели, например,

Императивная работа с транзакциями (через TransactionTemplate)

Кроме управления транзакциями через аннотации, Spring предоставляет возможность императивного управления транзакциями. Для этого Spring, как и во многих других случаях, использует шаблон «Template» (JdbcTemplate, RestTemplate). Используется класс TransactionTemplate . Bean продекларирован в TransactionAutoConfiguration . Основным методом является метод execute

который повторяет стандартный механизм rollback/commit:

получаем транзакцию (getTransaction)

выполняем действие (doInTransaction)

если была ошибка, откатываемся (rollbackOnException)

если все хорошо, то фиксируем транзакцию (commit)

Интересна строчка начала транзакции

Так как transactionManager является одновременно и TransactionDefinition (который мы настраиваем перед вызовом execute), то он передает самого себя в transactionManager , поэтому для транзакции используются те параметры, которые были переданы в transactionManager .

Так же можно заметить, что в метод выполнения передается TrsansactionStatus , поэтому во время выполнения вы можете вручную указать, когда нужно откатывать, не пробрасывая исключение

Обработка ошибок в HibernateTransactionManager

При работе с hibernate, даже если вы поймали ошибку и обработали ее, вы не сможете уже зафиксировать транзакцию, так как она будет помечаться как rollbackOnly (в отличие от работы с JdbcTemplate, например). Как это работает и почему?

Начнем с почему? — При работе с JPA вы не управляете последовательностью выполнения запросов и поэтому, если у вас произошла ошибка, hibernate не может восстановить правильный контекст и единственное, что ему остается, — пометить транзакцию как rollbackOnly

Как это работает? Если hibernate ловит ошибку, внутри себя он вызывает

который ставит флаг — rollbackOnly = true , даже если вы поймали эту ошибку и обработали. По логике Spring, если нет исключения, то вызывается PlatformTransactionManager.commit

При вызове PlatformTransactionManager.commit получаем статус транзакции, который внутри хранит флаг:

doCommit все равно вызывается и мы могли бы ожидать, что хоть что-то зафиксируется, но hibernate не имеет теперь консистентных данных, поэтому внутри hibernate есть такой код

Источник