Транзакции - Spring Framework в деталях

Транзакции являются важным инструментом для построения отказоустойчивых информационных систем, работающих в условиях постоянной высокой нагрузки и обеспечивающих одновременную работу десятков, сотен, а то и тысяч пользователей.
В этом ролике я постарался рассказать про проблемы, возникающие в многопользовательских информационных системах, про транзакции и требования ACID к транзакционным системам, уровни изолированности и распространение транзакций, а так же демонстрирую API для управления транзакциями, предоставляемые Spring Framework.
#java #spring #транзакции #transaction
Мой сайт: alexkosarev.name/
Паблик в VK: public218833461
Канал в Telegram: t.me/+TZCuO38vG3oqu_Jq
Стать доном: donut/shurik.codes
Донаты в Boosty: boosty.to/akosarev/purchase/1...
Донаты в Tinkoff: www.tinkoff.ru/cf/4PEOiVCZQuS

[@raccoon8230]

*Таймкоды:* 00:00:00 *Вступление* 00:01:40 *Проблемы при работе с данными* 00:02:35 *Понятие транзакции* 00:03:15 *Аномалии при параллельной работе с данными* 00:04:04 *Грязные чтения* 00:07:41 *Потерянные изменения* 00:10:46 *Потерянные изменения (атомарные операции)* 00:12:20 *Не повторяющиеся чтения* 00:14:27 *Чтение фантомов* 00:16:54 *Требования ACID* 00:17:40 *Atomicity (атомарность)* 00:18:19 *Consistency (согласованность)* 00:19:19 *Isolation (изолированность)* 00:20:06 *Durability (устойчивость)* 00:20:49 *Уровни изолированности транзакций* 00:21:25 *Read uncommitted* 00:22:59 *Read committed* 00:24:28 *Repeatable read* 00:25:57 *Serializable* 00:26:58 *Какой уровень выбрать?* 00:28:07 *Нюансы уровней изолированности в разных СУБД* 00:29:22 *Распространение транзакций (пропагация)* 00:30:10 *REQUIRED* 00:30:37 *SUPPORTS* 00:31:03 *MANDATORY* 00:31:23 *REQUIRES_NEW* 00:32:34 *NOT_SUPPORTED* 00:32:55 *NEVER* 00:33:16 *NESTED* 00:34:35 *Физические и логические транзакции* 00:35:50 *Практика* 00:37:36 *Управление транзакциями через @Transactional* 00:38:30 *Реализация @Transactional в Spring* 00:39:27 *Параметры аннотации @Transactional* 00:43:33 *Демонстрация работы @Transactional* 00:45:00 *Нюанс с вызовом @Transactional метода в пределах одного сервиса* 00:54:19 *Управление транзакциями с помощью XML-конфигурации* 01:00:29 *Управление транзакциями с помощью TransactionTemplate* 01:06:54 *Управление транзакциями с помощью TransactionManager* 01:14:51 *Какой способ выбрать?* 01:16:39 *Где располагать управление транзакциями?* 01:18:39 *Итоги* 01:19:17 *Полезный совет*

[@AlexandrGogichaev-ec7cv]

Дай Бог тебе здоровья, дружище!

[@raccoon8230]

Это пожалуй *самое понятное и всеобъемлющее объяснение* в российском сегменте KZbin 👍

[@spell3961]

У Вас очень крутой материал, на ютубе мало кто затрагивает такие темы))) Спасибо Вам и удачи!!!))))

[@devdev8158]

Ранее по крупицам собирал эти знания в конспекты, а тут все в одном видео. Огромное спасибо автору!

[@nikolaymatvienko1090]

Наконец-то новый фильм на выходной :)

[@user-lx4dc1ls3e]

очень нужная и крутая тема!!! Спасибо автору👍👍👍

[@Devivl]

Огромная благодарность за такой содержательный материал! Уголок сельского джависта - это находка для каждого, кто хочет саморазвиваться и понимать как оно работает изнутри. Большое спасибо не раз, Александр!

[@user-ss4nl3zb8v]

Без запинки говорит, как будто читает. Темы актуальные понимает. Спасибо!

[@vital708]

Блин, как круто что наткнулся на этот канал. Находка прям. Дибильные алгоритмы предлагают чаще всего всякий шлак, когда есть такое.... Приятно слушать, всё понятно. Подпись.

[@microlab982]

Спасибо за материал! Очень нравится подача, редко встретишь в ру сегменте и грамотную речь и качество материала)

[@MaximBodrov]

Много полезного, простая и наглядная подача. Спасибо автору!

[@vladdbafff8321]

Супер контент!! С нетерпением жду материала про реактивщину)

[@olegivanov3966]

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

[@ihorbalabai]

Спасибо за труд, все очень подробно и понятно. 👍👍👍 Было бы круто еще раскрыть, то как @Transational работает в связке с @Async

[@user-ii6fr3bn2f]

Мне твое видео очень сильно помогло на собеседовании хорошо раскрыть эту тему! Благодарю!)

[@user-pq7tk7gd2h]

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

[@denisnurdinov4618]

Спасибо за контент !)🔥

[@kovalevok]

Супер! Спасибо за материал

[@user-hi7yk5iv7j]

Очень познавательно, спасибо!

[@user-ii6fr3bn2f]

Спасибо тебе большое за подробный рассказ! 👍🏻

[@zvuk3316]

Спасибо за видео! Очень полезное)

[@raccoon8230]

Огромнейшее спасибо! 🔥

[@johnconnor3553]

очень хорошие ролики делаешь,особенно security нравится 👍 Спасибо.Здоровья тебе и твоим близким 🤗

[@iskygod5783]

Класс, спасибо за твои видео, наткнулся случайно на них, но из кучи контента как то зацепила подача информации. Я, правда, недавно в IT и свой путь начал с нагрузочника, но планирую в разрабы перейти, поэтому твои видео для меня открытие просто. В основном вся информация, которая попадает на ютубе, однообразная, то есть у всех как то однотипно сделано, без сложностей особых. Но для моего уровня видно, что ты уже опыт большой имеешь и много для меня непонятных моментов, из за которых приходится по 10 раз видео пересматривать и разобираться в коде. Да, не просто, в основном, много непонятного, но потом, после того, как разобрался, многое в работе кажется простым и за это спасибо) Удачи тебе и побольше подписчиков твоему каналу!) И знай, что есть люди, которые ищут хорошие каналы для обучения и однажды кто-то найдет твой и скажет спасибо, так что не останавливайся)

[@itmaker1821]

Очень полезно, спасибо

[@reestts]

Спасибо за видео!

[@paradiesd]

Очень крутое видео, спасибо, долго ждал новое видео

[@user-xs3wx8vy8g]

Спасибо! Отличный материал! Однозначно подписка.

[@Mannelig92]

Спасибо, всё отлично разобрано, подтянул себя по Транзакциям

[@klaimosfun6733]

Спасибо за видос, очень полезный

[@denwerxampp4035]

как всегда топ, все мы немного сельские программисты

[@abobu63]

спасибо огромное!

[@magistr011]

очень подробно без воды !!! Автор молодец!

[@stanley_ekb]

Спасибо тебе огромное ! Очень всё понятно объяснил. Подписался)

[@ZamalSpace]

О, да! Как раз хотел изучиить тему транзакции. Очень круто, спасибо! Я еще пока что не смотрел ролик, но уверен, что материал качественый. Ждем от тебя разбора Сессии, Кафки.

[@user-007-1]

Хорошее видео (ещё не смотрел, но знаю заранее) Хотелось бы послушать от вас про hibernate, там много нюансов, особенно в контексте сохранения/обновления/удаления сущностей с one to many, many to one, many to many, ну и про знаменитую n + 1)

[@user-007-1]

Особенно интересует кейс, когда есть сущность А, у которой есть 2 oneToMany (или manyToMany) коллекции зависимых сущностей B и C. И нужно достать лист сущностей А вместе с их зависимыми сущностями, причем с пагинацией (обычный джойн фетч не помогает) Есть несколько способов это сделать, хочется узнать, как лучше

[@shurik_codes]

Учтём пожелания

[@_F_A_K_I_R_]

Super!🔥

[@dmitrylemeshenko9642]

Спасибо!

[@alexshutov5442]

в поддержку)

[@baxiskerimzade2690]

Спасибо )

[@makskors5002]

Не, ну после такого точно подписка))

[@user-hb9od6th1d]

Лайк подписка жаль что так мало подписчиков, но со временем должны набраться, потому что контент полезный

[@user-gl1kd2ds4g]

Спасибо! Кстати, 53:00 - Spring поддерживает self-injection через @Autowired

[@mtuliakova]

Добрый день. Спасибо за огромную работу. Очень понятно объясняете! Комментарий на счет readOnly. Никакие исключения не выкидываются, если транзакция что-то будет писать в бд, этот флаг для оптимизации транзакции.

[@savax2718]

Клёво! Расскажи про Kafka плиз

[@adekakz9794]

очень жесткое видео - что касаемо знаний

[@dreamer_vi905]

15:03 "Чтение фантомов" тут небольшая оговорка. А так материал ценный. Спасибо.

[@ilyaakimov7498]

Жалко нельзя два плюса поставить видео, спасибо!

[@Po4kaKita]

По пожеланиям: - транзакционная отправка в кафку (постоянно слышу этот вопрос при разработке)

[@Eduard.Kardashov]

почитайте про паттерн outbox, реализация с помощью debezium

[@user-ti7wk4qt6s]

Это просто кладезь информации с очевидными примерами. Уже всем скинул ссылку на это видео. Наглядность примеров поразила! Подписался, теперь буду все смотреть :) Спасибо за проделанную работу! А можно ли комбинировать аннотации и темлпейт или менеджер? Последние нормально будут считывать пропагацию или уровни изолированности?

[@shurik_codes]

Да, комбинировать можно, в конечном итоге всё равно будет 2+ обращения к менеджеру, просто одно будет в АОП-совете

[@mikhail6694]

согласованность это как раз про бизнес требования

[@kassymbekoff]

Добрый день! Спасибо за шикарный урок! Какие книги можете посоветовать по транзакциям? И вообще книги - "must have" для Java разработчика?

[@shurik_codes]

По транзакциям - не скажу, по остальному: - Книги Роберта Мартина (в первую очередь "Чистый код" и "Чистая архитектура") - Паттерны объектно-ориентированного программирования - Книги про алгоритмы и структуры данных (Грокаем алгоритмы, Алгоритмы Скиены и Стивенса) - Книги посвящённые предметно-ориентированному проектированию (синюю и особенно красную) - Реактивные шаблоны проектирования

[@yuryklimchuk8271]

Мне кажется на 15:04 маленькая оговорка - имеется "это и есть неповторяющееся чтение" должно быть "чтение фантома"

[@dmitrii4223]

Очень информативный видос! Задаюсь вопросом, нужно ли оборачивать селект в транзакцию с изоляцией, например, read_committed? Если ее в транзакцию не завернуть, то поведение будет такое же - прочитаем только записи с зафиксированными изменениями. Или я что-то упустил?

[@shurik_codes]

Всё зависит от конкретной СУБД, но, поскольку read_uncommitted по умолчанию нигде не используется (вроде бы), все запросы и так выполняются в рамках транзакции с уровнем изоляции read_committed (например, в PostgreSQL) и выше (например, в MySQL). Так что в целом нет смысла. Смысл в ручном управлении транзакциями при операциях чтения появляется, когда, например, хочется ограничить общее время исполнения.

[@Po4kaKita]

Отличный ролик, как всегда! Можно название шрифта?

[@shurik_codes]

JetBrains Mono

[@eapashkov]

Вот и лето закончилось, вентилятор с кадра пропал(

[@shurik_codes]

Вернём в следующем году)

[@ilyasimonovets4639]

добрый день, а можете поделиться книгами для java разработчиков, которые читаете и можете посоветовать для развития? спасибо 🙌

[@xursandbeksherxonov3108]

Hello Mentor. Could you share about kafka with spring boot. Please!

[@shurik_codes]

Sure, I'll do it someday

[@raynur256]

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

[@user-vo5uk2jv8d]

Если у нас есть сервис с методом transactional в котором идет вызов двух других методов в других сервисах также с аннтоацией transactional, то при ошибке во втором сервисе откатится ли транзакция в первом?

[@shurik_codes]

Если выбран вариант пропагации, выполняющий код всех методов в одной транзакции (например, PROPAGATION_REQUIRED), то да.

[@user-vo5uk2jv8d]

@@shurik_codes Благодарю

[@karenpetrosian2979]

А это примеры на MySQL? Прошу автора помочь разобраться! Кажется в Postgres это работает не совсем так. Из того что прочитал на открытых ресурсах: Блокировка происходит на команды insert, update, delete, select for. Поговорим про read_comitted и repeatabble_read: Транзакция 1 делает изменения через update тем самым блокирует работу со строкой Транзакция 2 делает update ожидая пока транзакция 1 сделает коммит или ролбэк Сценарий для repeatabble_read: - Транзакция 1 делает коммит - Транзакция 2 видит что изменения были с этими данными (Postgre поддерживает версионноость) снимки с БД показали разные версии и Транзакция 2 откатывается! ВТОРОЙ ВАРИАНТ С РОЛБЭК - Транзакция 1 делает ролбэк - Транзакция 2 сделав снимок видит что изменений нет при update и деает транзакции выполнить этот скрипт! Теперь сценарий для read_comitted: - Транзакция 1 делает коммит - Транзакция 2 делает коммит

[@shurik_codes]

Конкретно в этом ролике примеры в MySQL

[@dimakuber9309]

A zachen implementacia interface final? V chem profit?

[@shurik_codes]

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

[@paradiesd]

Есть в планах работа с сессиями?)

[@shurik_codes]

Какие сессии подразумеваются? Если Hibernate/JPA, то когда доберусь до этой темы.

[@paradiesd]

@@shurik_codes я думал про сессии приложения именно

[@paradiesd]

@@shurik_codes Jpa/hibernate мне кажется многие хотябы имеют представление, а вот я не смог найти нормальные видео или рускоязычные статьи про сессии приложения.

[@shurik_codes]

@@paradiesd HTTP?

[@paradiesd]

@@shurik_codes Да, плюс конфигурация, чтобы можно было написать самому логику создания сессии , было бы мне кажется очень интересно

[@Boyarsskiy]

А для чего нужно было объявлять класс final? Без final можно было бы прямо на метод в классе аннотацию повесть бед хоровода с интерфейсом. UPD: пардон, досмотрел, для демонстрации было показано )

[@shurik_codes]

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

[@Boyarsskiy]

@@shurik_codes Ну если команда договорится, то можно и не расширять класс. Да и в 99% случаев никто не расширяет сервис в каком-нибудь CRUD. Но лезть в контекст спринга из класса с бизнес-логикой не лучший компромисс только ради поклонения советам из книг по clean code, которые вообще писались в отрыве от фреймворков и их особенностей. Этот код потом будет вызывать постоянные вопросы у других разработчиков, которые и не догадывались что весь хоровод только из-за ключевого слова final, так как так красивее. Я думал пример показан для экстремальных случаев, а оказалось это "распространённая практика".

[@MaximBodrov]

Не совсем понял, что автор подразумевал под "атомарной операцией" при потерянном изменении. set c_balance = c_balance - 100. Это атомарная?

[@shurik_codes]

Ну да, это атомарный UPDATE

[@alexanderkorovkin1990]

Автор ролика утверждает, что запрос "update t_account set c_balance = c_balance - 100 where id = 200" является атомарной операцией. Он говорит про базы данных, и насколько мне известно, он действительно прав. Но хотелось бы понимать, почему всё что выполняется в рамках одного оператора в базе данных является атомарной операцией?? В Java изменение поля balance = balance - 100 не являлось бы атомарной операцией, потому что поле balance сначала вычитывается, потом от него вычитается 100, и потом результат снова присваивается полю balance. За счёт чего в базах данных по-другому??

[@user-fh5yj5cr8d]

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

[@alexanderkorovkin1990]

@@user-fh5yj5cr8d всё-таки, как-то непонятно... Ну хорошо, открылся этот самый курсор, т.е. мы начали работу со снэпшотом данных на определённый момент. И что это меняет? К тому моменту как мы присваиваем полю c_balance значение c_balance(из снэпшота) - 100 другая транзакция могла поле c_balance уже поменять и закомитить. Получается потерянное обновление. Где здесь атомарность?

[@111111111si]

Мне кажется автор ошибся - lost update не допускается ни на одном из четырех озвученных уровнях изоляции.

[@shurik_codes]

В MySQL lost update даже на уровне изолированности Repeatable read проявляется, так что нет, я не ошибся, всё зависит от реализации конкретной СУБД. Я демонстрировал пример на уровне read uncommitted

[@shurik_codes]

Небольшое уточнение: аномалия с потерянными изменениями может проявляться в двух случаях. В первом может иметь место потеря изменений при выполнении атомарных операций без использования транзакций (напр, UPDATE T_ACCOUNT SET C_BALANCE = C_BALANCE + 100 WHERE ID = 1). В теории использование транзакций с любым уровнем изолированности должно решать эту аномалию. Во втором случае потеря изменений возникает при присвоении колонке нового значения, вычисляемого вне запроса на обновление. Пример такой транзакции был как раз продемонстрирован в ролике: BEGIN; SELECT @balance := C_BALANCE FROM T_ACCOUNT WHERE ID = 1; UPDATE T_ACCOUNT SET C_BALANCE = @balance + 100 WHERE ID = 1; COMMIT; И вот во втором случае всё зависит от реализации используемой СУБД: так MySQL теряет изменения даже при уровне изолированности транзакции REPEATABLE READ, а PostgreSQL - только на уровне READ COMMITTED, если память меня не подводит. Ну и есть мнение, что для решения второго варианта этой аномалии лучше использовать блокировки, а не полагаться на уровни изолированности транзакций.

[@foo44444]

используешь два монитора сразу, признавайся?!

[@shurik_codes]

Использовал, заменил на один 3440x1440

[@foo44444]

круто, и у меня такой был)@@shurik_codes

[@core2mind]

Read commited устраняет проблему потерянных изменений вроде бы. Может есть тонкости в конкретных СУБД, но данный ролик говорит в общем о существующем стандарте, и иногда упоминается некоторые специфичные вещи. ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B8%D0%B7%D0%BE%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B9 (Таблица в конце тоже об этом говорит) И строка "Стандарт SQL-92 определяет шкалу из четырёх уровней изоляции: Read uncommitted, Read committed, Repeatable read, Serializable. Первый из них является самым слабым, последний - самым сильным, каждый последующий включает в себя все предыдущие." также на это намекает В видео сказано (23:25), что нет

[@shurik_codes]

Из ответа к другому комментарию: Аномалия с потерянными изменениями может проявляться в двух случаях. В первом может иметь место потеря изменений при выполнении атомарных операций без использования транзакций (напр, UPDATE T_ACCOUNT SET C_BALANCE = C_BALANCE + 100 WHERE ID = 1). В теории использование транзакций с любым уровнем изолированности должно решать эту аномалию. Во втором случае потеря изменений возникает при присвоении колонке нового значения, вычисляемого вне запроса на обновление. Пример такой транзакции был как раз продемонстрирован в ролике: BEGIN; SELECT @balance := C_BALANCE FROM T_ACCOUNT WHERE ID = 1; UPDATE T_ACCOUNT SET C_BALANCE = @balance + 100 WHERE ID = 1; COMMIT; И вот во втором случае всё зависит от реализации используемой СУБД: так MySQL теряет изменения даже при уровне изолированности транзакции REPEATABLE READ, а PostgreSQL - только на уровне READ COMMITTED, если память меня не подводит. Ну и есть мнение, что для решения второго варианта этой аномалии лучше использовать блокировки, а не полагаться на уровни изолированности транзакций.

[@core2mind]

@@shurik_codes , понятно, не привычно просто слышать о проблеме потерянных изменений в таком ключе. Когда говорят о кейсе потерянного изменения имеют ввиду возможность этих потерь именно исключительно при апдейте, абстрагируясь от кейса предварительного чтения (для вычисления значения изменяемых данных). Поэтому эта проблема и рассматривается как самая наименьшая и решаемая любым уровнем изоляции. А кейс чтения перед изменением - это чаще оговорка в процессе рассказа о грязном чтении. Ну потому что корень проблемы в том, что прочитанные ранее данные уже неактуальные (то есть проблема больше в ранее прочитанном, а не при изменении). В вики этот кейс, как я понял, тоже вынесен в раздел грязного чтения (хотя сам он в большой степени, конечно, про чтение незакомиченного и откатанного). Но я понял вас, спасибо.