🚀 Новый разбор: Spring @Transactional, Propagation и Proxy

В этом видео я показываю:

🔸 Как работает аннотация @Transactional в Spring
🔸 Что такое разные Propagation и как они работают
🔸 Свой пример Proxy, чтобы понять как под капотом Spring создает и откатывает транзакции

📹 Смотрим видео на YouTube:
🔗 ▶ Смотреть

💻 Репозиторий с кодом:
🔗 GitHub

Ламповые домашние рассуждения поехавшего профессора, в которых он затрагивает, в том числе, и этот видос: https://youtu.be/o2xAkuBf9W4?si=Z4IOlda2ubZfjqKZ

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

💡 Когда и где использовать @Transactional в Spring?

После выхода последнего видео получил хороший вопрос:

"А когда вообще стоит использовать @Transactional? Например, для методов getAll, getById, create, update, delete — нужно ли? И создает ли она дополнительную нагрузку?"

Выше оставил маленькую шпору, а ниже разбирем всё по порядку 👇

📌 1. Где использовать?
@Transactional имеет смысл в методах, где мы меняем состояние базы данных — то есть выполняем INSERT, UPDATE или DELETE.
Это:

🔸create
🔸update
🔸delete

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

‼️ Особенно важно оборачивать транзакцией методы с несколькими изменениями — тогда в случае ошибки все изменения откатятся.

А вот если у вас всего один апдейт, то @Transactional технически не обязателен — драйвер JDBC и так выполняет операцию в транзакции (если надо расскажу об этом подробнее). Но вешать её можно для единообразия, особенно если логика метода со временем может вырасти.

📌 2. Нагрузка на БД
Транзакция сама по себе — не "тяжёлая" операция, но:

1. Держит соединение с БД дольше
2. Может блокировать строки или таблицы (зависит от уровня изоляции)
3. В случае долгих транзакций — мешает другим запросам

Поэтому не транзакционируем всё подряд, особенно долгие чтения.

📌 3. Нагрузка на приложение
Spring при использовании @Transactional создаёт прокси и оборачивает вызов метода в транзакционный менеджер.
Эта накладка минимальна, а основная "стоимость" транзакций всегда на стороне базы.

💬 Итог:

1️⃣ Несколько изменений в БД → транзакция обязательна
2️⃣ Один апдейт → можно без неё, но допустимо вешать для консистентности
3️⃣ Чтение → транзакция редко нужна, но бывают исключения

⚡ Это базовые принципы, но транзакции ещё и по-разному взаимодействуют друг с другом: одни продолжают существующую, другие создают новую, третьи вообще запрещают выполнение внутри транзакции.
Подробно об этом я рассказал в новом видео — в котором разобрал параметр Propagation и показал на примере как оно работает под капотом

🎥 Ссылка на видео: https://youtu.be/ZWuvSOCRs3Q?si=TPUYjcVto42gfHMp

Попросил ChatGPT нарисовать мне баннер для YouTube канала, на основе всего того, что он обо мне знает.

Похож? 😂

Судя по всему знает он обо мне многое, кроме того, что я НОШУ ЧЕЛКУ ТОЛЬКО ВПЕРЕД!!! 🤣

💻 Совсем немного Java Core
🔥 И ты забудешь про хардкор
⚡ А чтоб сервак твой не упал
👉 Вступи скорее в мой канал

Короче, всем привет!

У меня на канале — и думаю, никто не будет с этим спорить — ублюдская шапка:

📩 Для связи: @zor_07
📚 обучающие материалы по Java
✅ Пет-проекты
✅ Помощь в составлении резюме
✅ Подготовка к собесам

Какие-то всратые галочки. Люди на это смотрят и такие: «Ну нахер…» — как в том меме со священником.

Короче, надо придумать новую шапку.

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

🙏 ПАМАГИТЕ!
Мне нужна новая шапка. 🥹

📏 Ограничения:
— немного скрытой эротизации — маст хэв
— но так, чтобы было понятно: мы всё-таки порой и про Java разговариваем
— максимум 255 символов (вместе с пробелами и эмодзи)

Вот мои варианты:

💡 Войти в Java, чтоб сервак не упал, а жизнь не переставала возбуждать?
Невозможно — скажете вы. Просто подпишись — отвечу я.

💡 Как выучить Java, чтоб твой сервак никогда не падал?
За 10 лет я этого так и не понял. Но ты залетай — будем разбираться вместе.

Все ещё ВСРАТО. Мне не нравится.

✍️ Накидайте ваши варианты для описания канала.
🏆 Победителю, чей вариант я использую (или отрефакторю и заюзаю), — бесплатная консультация на любую тему (хоть сколько-нибудь близкую к Java).

👉 Варианты от GPT для разгона

💡 «Java без боли и уныния: чтобы код компилился, сервак не падал, а жизнь стояла колом от удовольствия. Подписывайся — будем разбираться вместе 🍅»

💡 «Как выучить Java и не потерять стояк на жизнь? Тут и про Spring, и про базы, и про то, как не сойти с ума на собесах. Влетаешь — дальше только веселее 🚀»

🤪 Дичайшие варианты от GPT

💡 «Java и стояк на жизнь: одно поддерживаем транзакциями, другое — кофеином ☕. Подписывайся, пока GC не собрал твой энтузиазм!»

💡 «Освоишь Java — сервак не упадёт. Подпишешься сюда — и либидо тоже. Тут баги фиксят не только в коде, но и в душе ❤️»

💡 «Канал о Java: чтобы твой код не вис, сервак не падал, а стояк не прерывался даже после дедлайна ⏳🍆»

💡 «Java, Spring и немного эротики: чтобы не только тесты проходили, но и ты всегда был готов к нагрузочному 😏»

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

Все произошло как-то импульсивно. Просто сел, и решил сразу начать запись как пойдет. Ай как хорошо у меня все получалось. Лайв кодинг с пояснениями, размышлениями. Что за лев был этот тигр.

1.5 часа безудержного кодинга. А по итогу что? По итогу этот тигр не включил микрофон 🎤 🤦‍♂️

Короче да, перезапишу в скором времени, но пока что это фиаско, братан 😂

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

Задачи довольно сложные. Кодовая база не просто большая, а 🤬 какая большая. Более 100 микросервисов + несколько монолитов.

Фикшу баги, занимаюсь аналитическими задачами.

Была аналитическая задача узнать на какую максимально возможную версию можно поднять один крайне важный инфраструктурный компонент.

Пока я ею занимался вдруг что-то крайне важное и нужное сломалось на проде.

Я описываю в общих чертах без конкретики, так как не хочется случайно нарушить nda, но в общих чертах поделиться все равно хочу.

Сломалось что-то важно и нужное прям каждый день. Клиенты страдали от этой поломки. Нужно было сделать фикс максимально быстро. Замедлилась обработка сообщений в одном брокере сообщений. И надо было понять почему. С учетом размера кодовой базы и отсутствием доступа к логам прода понять это было не то чтобы очень просто.

За первый день удалось разобраться в принципе как эта херабора работает.

За второй день удалось выкатить костыль, который позволил не задерживать обработку сообщений в этой очереди.

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

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

Решая эту проблему вдруг пришла мысль: «теперь понятно, почему мне платят такие деньги»

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

Вот представьте - 100 микросервисов, какие-то из них читают из очередей. Сейчас поддерживается ордеринг сообщений. Т.е. сообщения читаются в том порядке, в котором были отправлены. А в новой версии ордеринг не будет гарантироваться, и надо понять сломает ли это что-нибудь.

К понедельнику (истерический смех).

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

Поделитесь плз, читаете ли вы книги? И если да, то как?

- Бумажные
- В читалках электронных?
- На телефонах/планшетах? Какие юзаете приложения-читалки?

И как вы выбираете что почитать? Как приходит понимание, что вот эту книжку я почитать хочу?

Думаю снова вернуться к чтению и хочу понять какой формат был бы удобным для меня)

Завтра будет новый видос 😱
@AivenDemin, кажется, он тебе понравится)

А я тут рилсик запилил, и в мотиваторы подался 🌚

Я как-то снимал видос про докер на YouTube.

И недавно пришел чел, и сказал:
- Непонятно, поясни за эти файлы (см скрин)

А мне лень все это расписывать, тем более, что я когда-то делал урок на эту тему в своем курсе.

Поделился с ним уроком. С вами тоже поделюсь, вдруг кому полезно будет.

Урок в коментах.

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

Залетайте короче

Самый важный навык программиста.

Привет! В этом посте поделюсь своими мыслями по следующим вопросам:

1. Что самое сложное в работе программиста?
2. Какой скилл является самым важным?
3. Куда расти: вглубь или вширь?

В программировании способов реализовать какую-то задачу — вагон и маленькая тележка.

И представьте: собралась команда разработчиков, и им нужно реализовать какой-то большой проект. В этой команде могут быть как новички, так и древние мамонты. Новички учились по туториалам и никаких других способов реализовать задачу не знают. Ну а древние мамонты могут быть тоже разные. У одних расцвет сил пришёлся на времена Java 1.0, и в голове могут быть крутые, но чуть устаревшие знания. А могут быть и крутые мамонты, которые решают задачу элегантно: ты смотришь на их код и думаешь: «Боже, как круто! Как круто и непонятно».

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

Проект живёт, кодовая база растёт, люди уходят и приходят.

И в какой-то момент появляешься ты. Ты проходишь онбординг, настраиваешь IDE, получаешь доступы, скачиваешь проект и такой:

«Господи, что это такое?!»

Ты видишь столько кода и не понимаешь — это говно или так надо по объективным причинам. А если ты новичок, то смотришь на говно и думаешь, что это апогей алгоритмической мысли.

И если ты не сидел в проекте со времён распада СССР, то самым сложным в твоей работе будет одно:

Разобраться, как это говно работает и как бы тебе вклинить свой код, не нарушая принятых в команде договорённостей.

И чем сложнее задача, тем больше времени придётся тратить именно на это: на чтение и понимание чужого кода. Умение разобраться в чужом коде — это навык, который будет использоваться 88% твоего рабочего времени.

Это самое сложное, но, на мой взгляд, не самое важное в работе программиста.

Что же является самым важным?

Написать свой код так, чтоб спустя годы тебя не прокляли. А ещё лучше — чтоб не прокляли в тот же миг.
Тебе может показаться, что твой код проходит ревью, и, как бы, «старшие коллеги» берут часть ответственности на себя за то нечто, что породил ты в больном бреду, пытаясь понять, как оно всё тут принято. Но это далеко не всегда так. Ревью делают такие же люди как и ты. И ты будешь делать ревью и ловить себя на мысли, что хочется поставь аппрув "ради галочки", вроде бы все тут хорошо....

Если ты программируешь уже какое-то время и даже писал пет-проекты, то, возможно, замечал: возвращаясь спустя время к своим старым проектам, ты задумчиво чешешь свою репу и думаешь: «Господи, это же я писал, почему я ничего не понимаю?!». А это только ты, в маленьком проекте. Помножь эту ситуацию на бесконечность — и получишь некоторое (хоть и не полное) представление о том, что тебя ждёт, если ты не научишься писать код МАКСИМАЛЬНО ПРОСТО И ПОНЯТНО.

Это и есть самое важное — уметь писать понятный код. Не только тебе, но и другим людям.

Как к этому прийти?
Нет быстрого способа. Нужно породить тонну говна и с опытом обрести понимание того, «что такое хорошо, а что такое плохо».

Ну и куда расти?

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

Но это и не нужно. Благо, несмотря на всё это многообразие, под капотом везде заложены одни и те же принципы, которые придумали «когда наши родители были молодыми» люди, которые в разы умнее самого умного твоего знакомого.

Если у тебя получится хорошо (плюс-минус) разобраться в какой-то одной технологии, то освоить другие не составит большого труда. Поэтому моё имхо: не нужно бросаться учить всё подряд. Всё не выучить. И не угадать, что надо учить.
Сосредоточься на чём-то одном и долби в эту точку. А остальное поймёшь по ходу.

Всем добра, хорошей пятницы и прекрасных выходных!

Кто лучший программист (все еще), человек или машина?

Полное исследование можно почитать по ссылке.

Ниже перевод вступления

Генерация кода с помощью LLM (вместо написания кода с нуля) резко выросла в популярности. Однако последствия для безопасности такого кода остаются неизвестными.

Мы провели исследование, сравнив безопасность и качество кода, написанного людьми, с кодом, сгенерированным LLM, на широком наборе задач: структуры данных, алгоритмы, криптографические процедуры и задачи уровня LeetCode.
• Для оценки безопасности использовались модульные тесты, fuzzing и статический анализ.
• Для оценки качества учитывались сложность и размер кода.

Результаты:
• LLM может генерировать некорректный код, который не реализует требуемый функционал, особенно на сложных задачах. Ошибки могут быть тонкими.
Пример: реализация алгоритма SHA1 компилировалась, но была неверной.
• Даже если функциональность верная, код от LLM часто менее безопасен: отсутствуют защитные конструкции (defensive programming), что приводит к уязвимостям (переполнение буфера, переполнение целых чисел).
• Fuzzing показал, что код от LLM чаще подвержен зависаниям и крашам, чем написанный человеком.
• По качеству: LLM генерирует «скелетный» код без защитных конструкций, при этом более сложный на строку кода, чем человеческий.

Попытка улучшить:
Мы создали цикл обратной связи: просили LLM повторно сгенерировать код и устранить найденные проблемы (например, malloc overflow, выход за границы массива, null dereference).

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