Spring Events и транзакции - какие варианты?

Есть такая полезная библиотека как Spring Events https://www.baeldung.com/spring-events. Позволяет логически и\или физически разделять операции внутри сервиса используя событийную модель. Event-drive architecture или паттерн Хореография, но не между микросервисами, а внутри. Но ключевое отличие взаимодействий между микросервисами и внутри микросервиса - внутри микросервиса есть транзакции в БД. Между микросервисами - в теории тоже, используя JTA, но лучше не надо)

Так вот, какие могут быть варианты по работе с транзакциями при использовании Spring Events? Используем Spring Data JPA, есть две операции - создание клиента и генерация для него токена, по бизнесу мы хотим их разделить. Получится как-то так:

1)
public Customer createCustomer(String name) {
final Customer customer = customerRepository.save(new Customer(name));
applicationEventPublisher.publishEvent(new CustomerCreated(customer.getId()));
}

...

@EventListener
public void generateToken(CustomerCreated customerCreated) {
final Long customerId = customerCreated.getId();
final Customer customer = customerJpaRepository.findById(customerId).get();
customer.generateToken();
customerRepository.save(customer);
}
В данном случае выполнение синхронное (режим работы Spring Events по умолчанию), т.е. первая операция ждет пока все подписчики обработают событие. Следовательно, разделение процессов только логическое, что тоже может быть полезно. Обращения к БД выполняются в разных транзакциях, т.к. транзакции не используются)

2)
@Transactional
public Customer createCustomer(String name) {
final Customer customer = customerRepository.save(new Customer(name));
applicationEventPublisher.publishEvent(new CustomerCreated(customer.getId()));
}

...

@EventListener
public void generateToken(CustomerCreated customerCreated) {
final Long customerId = customerCreated.getId();
final Customer customer = customerJpaRepository.findById(customerId).get();
customer.generateToken();
customerRepository.save(customer);
}

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

3)
@Transactional
public Customer createCustomer(String name) {
final Customer customer = customerRepository.save(new Customer(name));
applicationEventPublisher.publishEvent(new CustomerCreated(customer.getId()));
}

...

@TransactionalEventListener
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void generateToken(CustomerCreated customerCreated) {
final Long customerId = customerCreated.getId();
final Customer customer = customerJpaRepository.findById(customerId).get();
customer.generateToken();
customerRepository.save(customer);
}

Тут мы добавили 2 аннотации на вторую операцию, т.к. хотим обе операции выполнить в разных транзакциях. @TransactionalEventListener приводит к тому, что событие выполняется после завершения исходной транзакции, а @Transactional(propagation = Propagation.REQUIRES_NEW) открывает новую. Т.е. TransactionalEventListener не выполняет код в родительской транзакции, а синхронизирует выполнение с ней (и у него есть несколько режимов синхронизации). При этом исполнение по прежнему синхронное.

4)
@Transactional
public Customer createCustomer(String name) {
final Customer customer = customerRepository.save(new Customer(name));
applicationEventPublisher.publishEvent(new CustomerCreated(customer.getId()));
}

...
@Async
@EventListener
public void generateToken(CustomerCreated customerCreated) {
final Long customerId = customerCreated.getId();
final Customer customer = customerJpaRepository.findById(customerId).get();
customer.generateToken();
customerRepository.save(customer);
}
...
@Configuration
@EnableAsync
public class AsyncConfig {
}

Зачем нужен MQ?

По работе передо мной периодически встает данный вопрос - зачем нужен MQ? Нужен ли он?

Поясню. Мы давно и успешно перешли с ESB поверх IBM WebSphere MQ на Kafka. Стало сильно лучше. В первую очередь за счет того, что получить топик Kafka, выпустить сертификаты и настроить ACL сильно проще, чем заказать доработку для на ESB. Да, это проблемы ESB, а не MQ, но их исчезновение все сразу заметили) Второй плюс: появились persistence и возможность повторной вычитки сообщения в случае сбоя - и сильно увеличилась надежность решения. И конечно же Kafka быстрее.

Как итог - Kafka используется везде и всегда. При этом есть понимание, что кроме Kafka есть другие инструменты, реализующие паттерн очередь (queue). Долгое время не мог сформулировать - в каких кейсах нужны очереди?
Ведь паттерн publisher-subscriber, реализованный в Kafka, является более общим, чем очередь. И т.об. очереди - асинхронное взаимодействие с одним producer и одним consumer - вроде бы можно делать в и Kafka. А возможность везде использовать один инструмент - это плюс.

Но если подумать - суть не в реализуемом паттерне. Ключевые отличия у Kafka и RabbitMQ (взял самую известную реализацию очередей для конкретики) другие. Покажу их на примере того, чего Kafka не умеет:

1) Kafka не удаляет сообщение после вычитки. Удаляет позднее, по TTL, вместе с партицией, но это другой алгоритм и другой use case. Т.е. первая потенциальная причина выбора очередей - необходимость гарантировать, что вычитанное одним потребителем, никогда не вычитает другой. Не скажу, что это частый кейс - возможно, требования безопасности.

2) Kafka имеет достаточно ограниченные возможности по маршрутизации. По сути на клиенте можно выбрать топик и партицию по определенному ключу. Вот и вся маршрутизация. Причем это было сделано сознательно, для достижения высокой производительности. Если нужна более сложная маршрутизация - это критерий для выбора очереди вместо Kafka. Тоже кейс не частый, и есть альтернатива в виде реализации маршрутизации на клиенте.

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

4) у Kafka свой протокол. Поэтому если нужна поддержка существующего решения, где используется AMPQ или JMS - это не к Kafka. Особый случай, но упомянуть его надо.

Вот пожалуй и все варианты, когда Kafka не подходит.

P.S. Если знаете еще кейсы - напишите, плиз, в комментариях.

#mq #kafka

Можно ли быстро сделать и запустить single-file прототип на Java?

Как старый джавист я всегда немного с завистью смотрел видео, где человек на Python, PHP, Ruby пишет скрипт, содержащий достаточно сложный код и просто запускает его командой python script.py.
Не сказать, что Java ничего не делает в эту сторону:
1) JShell - позволяет просто запускать Java код без метода main построчно. Работает начиная с Java 9
2) JEP 330: Launch Single-File Source-Code Programs - не надо отдельно вызывать javac. Запуск программы работает через java HelloWorld.java. Работает с Java 11
3) JEP 477 Implicitly Declared Classes and Instance Main Methods - все тоже самое, но теперь не нужно объявлять класс (он создается неявно) и декларация метода main сильно упрощена. В режиме preview с Java 21

Но все это работает с простыми приложениями. А если нужны зависимости? Наш любимый Spring, например, с pom bom и кучей библиотек + Lombok. Да еще в нескольких файлах. Да еще хотелось бы не указывать параметры сборки в командной строке каждый раз, и не плодить лишних shell скриптов.
Когда-то подобная фича была в Spring Boot Cli - да, в Spring Boot и своя консоль. Но фичу выпилили, на мой взгляд зря. И из полезного в Cli остался по сути только аналог Spring Initialzr.
Но я отвлекся)

Кто ищет, тот всегда найдет - встречаем https://www.jbang.dev/documentation/guide/latest/index.html
Как это работает - хорошо проиллюстрировано по ссылке выше.
Я проверил на комбинации Spring Boot + Lombok все работает. Настройки из лежащего рядом application.properties подтягиваются. Единственный момент - были проблемы, если код разнесен по нескольким файлам - не обнаруживалась аннотация @Scheduled. Т.е. реализация multiple source file немного хромает, о чем разработчики предупреждают https://www.jbang.dev/documentation/guide/latest/organizing.html
Зато - все зависимости выкачиваются, код компилируется перед запуском, параметры компиляция настраиваются в файле с исходниками. Если надо - даже выкачивается Java. Принимает на вход java исходники, kotlin, упомянутый выше код для jshell, код внутри markdown (!!!) и можно даже так: jbang --code System.out.println("Hello World!")

Рекомендую к использованию!

#java #prototyping

Небольшая заметка к предыдущему посту.

Может возникнуть вопрос: зачем нужно сохранять настройки форматирования, он же code style,  в отдельном файле, если правильные настройки есть в IDEA по умолчанию? И изучать, пусть и поверхностно, пусть и достаточно простой формат настроек .editorconfig? Стоит ли игра свеч?

Мой ответ: да.

Во-первых, не все пользуются стандартными настройками IDEA. Во-вторых, они от версии к версии могут меняться. А единый code style — основа для комфортной и быстрой работы ревьювера. Почему важно code review — говорить не буду.

И пару уточнений. Даже в базовом стандарте .editorconfig много настроек. Плюс он позволяет сохранять вообще любые настройки, например, можно импортировать все настройки IDEA. Попробуйте, кстати, удивитесь. Вопрос: нужно ли всё это хранить в Git? Нет, это лишь затруднит управление настройками. Определитесь, что важно для быстрого чтения кода. Если что-то забудется — всегда можно добавить потом.

Второй вопрос — ведь IDEA тоже позволяет сохранять часть своих настроек, в том числе и настройки стиля кода. Как я вижу, эта опция не пользуется популярностью среди разработчиков, и я по данному вопросу с ними солидарен. Причин две: есть сомнения, что нужно сохранять именно этот набор — слишком уж много там файлов. И есть сомнения в совместимости между версиями IDEA, и особенно между её сборками (я про GigaIDE и аналоги). Не говоря уже о других IDE, типа VSCode.

P.S. И всё равно приличный объём поста получился.

#ide #codestyle #eac

Популярность ChatGPT

Недавно читал комментарии в телеге и понял, что ChatGPT, или в конкретном случае DeepSeek, уже стали мейнстримом.

Как я это понял?

Начну издалека. Давным-давно, когда программистов ещё не было, а люди, не желающие разбираться в сложных вопросах, уже были, — можно было сослаться на мнение других. Люди говорят, значит, так оно и есть. Потом появились газеты, в условной «Правде» написали — всё, безоговорочно верим. Потом в телевизоре сказали. Интернет, наконец — Google нашёл, в блоге написали — что тут думать?

Так вот, наши дни. В комментариях обсуждают CAP-теорему. Не слишком ли она теоретическая, стоит ли вообще обсуждать partitioning, если реальных систем, для которых partitioning (временное разделение распределённой системы на части, обмен информацией между которыми нарушен) является допустимым режимом, нет? Т. е., если P из CAP нам нужен всегда, то можно это зафиксировать и обсуждать выбор между consistency и availability.
И в комментарии пришёл человек и написал: зачем всё это обсуждать, ведь даже DeepSeek-у всё ясно. Если вероятность, что это был бот, но, к сожалению, скорее всего человек.

Вывод будет такой: да, ИИ отбирает аудиторию у блогов и поиска, но не всегда приводит к прорыву.

#ai