Транзакции Sapsan-Code

Атомарность
Атомарность гарантирует, что никакая транзакция не будет
зафиксирована в системе частично. Будут либо выполнены все её
подоперации, либо не выполнено ни одной. Поскольку на практике
невозможно одновременно и атомарно выполнить всю
последовательность операций внутри транзакции, вводится понятие
«отката» (rollback): если транзакцию не удаётся полностью завершить,
результаты всех её до сих пор произведённых действий будут отменены
и система вернётся во «внешне исходное» состояние — со стороны
будет казаться, что транзакции и не было (естественно,
счётчики, индексы и другие внутренние структуры могут измениться, но,
если СУБД запрограммирована без ошибок, это не повлияет на
внешнее её поведение)

4.

Согласованность
Транзакция, достигающая
своего нормального
завершения (англ. end of
transaction, EOT) и тем
самым фиксирующая свои
результаты, сохраняет
согласованность базы
данных. Другими словами,
каждая успешная
транзакция по определению
фиксирует только
допустимые результаты. Это
условие является
необходимым для
поддержки четвёртого
свойства.

5.

Изоляция
Во время выполнения транзакции параллельные
транзакции не должны оказывать влияния на её
результат. Изолированность — требование дорогое,
поэтому в реальных базах данных существуют режимы,
не полностью изолирующие транзакцию (уровни
изолированности, допускающие фантомное чтение и
ниже).

6.

Устойчивость
Независимо от проблем на нижних уровнях (к примеру,
обесточивание системы или сбои в оборудовании)
изменения, сделанные успешно завершённой
транзакцией, должны остаться сохранёнными после
возвращения системы в работу. Другими словами, если
пользователь получил подтверждение от системы, что
транзакция выполнена, он может быть уверен, что
сделанные им изменения не будут отменены из-за
какого-либо сбоя.

7.

Транзакции в Java Spring
With transactions configured, we can now annotate a bean with @Transactional either at
the class or method level:
Аннотация поддерживает и другие настройки:
• тип распространения транзакции(Propagation Type )
• уровень изоляции транзакции(Isolation Level)
• таймаут для операции, обернутой транзакцией(Timeout)
• флаг readOnly - подсказка для провайдера персистентности, что транзакция должна быть
только для чтения(readonly flag)
• правила отката для транзакции.(Rollback rules)
Обратите внимание, что по умолчанию откат происходит только для непроверенных
исключений. Проверенное исключение не вызывает откат транзакции. Конечно, мы можем
настроить это поведение с помощью параметров аннотации rollbackFor и noRollbackFor.

8.

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

9.

Required Propagation
REQUIRED - это распространение по умолчанию. Spring проверяет, существует ли активная
транзакция, и если ничего не существует, то создается новая. В противном случае бизнеслогика добавляется к текущей активной транзакции:
Более того, поскольку REQUIRED является распространением по умолчанию, мы можем
упростить код, отказавшись от него:

10.

Required Propagation
Давайте посмотрим псевдокод того, как работает создание транзакции для
распространения REQUIRED:

11.

Supports Propagation
Для SUPPORTS Spring сначала проверяет, существует ли активная транзакция. Если транзакция
существует, то будет использована существующая транзакция. Если транзакции нет, то выполняется
нетранзакционный процесс:
Давайте посмотрим псевдокод того, как работает создание транзакции для
распространения Supports:

12.

Mandatory Propagation
Когда распространение является ОБЯЗАТЕЛЬНЫМ, если есть активная транзакция, то она
будет использована. Если активной транзакции нет, Spring выбрасывает исключение:
Давайте посмотрим псевдокод того, как работает создание транзакции для
распространения Mandatory:

13.

Never Propagation
Для транзакционной логики с распространением NEVER Spring выбрасывает исключение,
если существует активная транзакция:
Давайте посмотрим псевдокод того, как работает создание транзакции для
распространения Mandatory:

14.

Not Supported Propagation
Если текущая транзакция существует, Spring сначала приостанавливает ее, а затем бизнеслогика выполняется без транзакции:
JTATransactionManager поддерживает реальное приостановление транзакции "из
коробки". Другие имитируют приостановку, удерживая ссылку на существующую
транзакцию и затем очищая ее из контекста потока

15.

Requires New Propagation
Когда распространение имеет значение REQUIRES_NEW, Spring приостанавливает текущую
транзакцию, если она существует, а затем создает новую:
Аналогично NOT_SUPPORTED, нам нужен JTATransactionManager для фактической
приостановки транзакции.
Псевдокод выглядит следующим образом:

16.

Nested Propagation
При распространении NESTED Spring проверяет, существует ли транзакция, и если да, то
отмечает точку сохранения. Это означает, что если при выполнении бизнес-логики
возникнет исключение, то транзакция откатится к этой точке сохранения. Если активной
транзакции нет, то все работает как REQUIRED.
DataSourceTransactionManager поддерживает это распространение "из коробки".
Некоторые реализации JTATransactionManager также могут поддерживать это.
JpaTransactionManager поддерживает NESTED только для соединений JDBC. Однако если мы
установим флаг nestedTransactionAllowed в true, это также работает для кода доступа JDBC в
транзакциях JPA, если наш драйвер JDBC поддерживает точки сохранения.

17.

Homework
1.Создайте базу данных с двумя таблицами: "Users" и "Orders". Таблица "Users"
должна содержать информацию о пользователях, а таблица "Orders" - информацию
о заказах, которые сделали пользователи.
2.Напишите приложение Spring Boot, которое позволяет пользователям делать
заказы. Приложение должно иметь следующие функции:
•Регистрация пользователя
•Авторизация пользователя
•Просмотр списка товаров, доступных для заказа
•Создание нового заказа
•Просмотр списка заказов пользователя
3.Реализуйте транзакции в приложении. Транзакции должны использоваться при
создании нового заказа. Если какой-то из товаров недоступен для заказа,
транзакция должна откатываться, чтобы избежать ошибок в базе данных.
4. Добавьте авторизацию и аутентификацию
Удачи!

English Русский Правила