Комментарии 12
Тоже задумал мигрировать сервлетное приложение Spring boot на реактивную платформу. Правда у меня стек полностью котлин, там еще надо ужить WebFlux с suspend. Но вроде это наименьшая головная боль в миграции. Миграцию решил делать прозрачную, так чтобы фронтэнд даже этого не заметил и с минимальными правками бизнес логики. Тоже столкнулся с совмещением реактивных и нереактивных библиотек, но на данном этапе завести все вместе пока не получилось, хотя по части бизнес логики, в сервисном слое действительно правок у меня не много. Чего не скажешь про слой хранения данных. Вот где геморроя полно. Весь код придется переписывать, ибо из того, что я нарыл - R2DBC и Hibernate Reactive - совместимость никакая, у хибера процентов 70%, у r2dbc - 20%. Хибернетовские 70% еще куда ни шло, но у меня реактивный хибернейт очень плохо ложится на Котлин и Spring. Из вашей статьи надеюсь вынесу полезный опыт, спасибо за то что поделились.
Для Hibernate Reactive (а точнее для smallrye-mutiny, который в нём используется) есть возможность выполнить преобразования Uni/Multy <-> Mono/Flux. Так что если сейчас используется JPA/Hibernate, особых проблем быть не должно.
Спасибо большое. Да, наверное это как-то получится уложить в рамки моего приложения. Ситуация у меня чуть сложнее, чем в таком же приложении, но на Java. Я решил делать всё в Котлин-way c suspendable. Project Reactor дает легкое преобразование из Mono и Flux в suspend вызов, через executeAndAwait например. Uni/Multi я такого не нашел, но ваша ссылка вроде дает подсказку, в каком направлении копать.
А вы не знаете, есть ли в реактивном Хибернейте @Repositoryстиль написания обращений к бд, чтобы не городить сложные конструкции с кодом JPQL/HQL. Написал в интерфейсе метод без тела, например findById и Хибернейт понял, что я хочу. R2DBC такое поддерживает, например.
Такого нет. И чистый r2dbc это тоже не поддерживает. Это фишка Spring Data JPA, который может быть обёрткой для r2dbc. И я бы не сказал, что в Repository получается намного меньше кода. + для сложных запросов можно использовать query-dsl, который дружит с хибером.
Я хотел @Repositoryиспользовать исключительно для минимазации изменений в коде, как это работает с теми же @Entity, по сути переход очень малозатратный в случае с сущностями, ничего править не нужно, соответственно возможно переиспользование кода, так как у меня миграция - это совмещение старого кода с новым реактивным. Поэтому я ищу легкий путь, а не заниматься дублированием кода, так как разработка ведется паралелльно с миграцией. За ссылку query-dsl спасибо, давно приглядываюсь к нему, так как в своей время, не найдя что-то похожее, пришлось писать такую библиотеку самому
Если у вас реляционная база, то какие выгоды перехода с jdbc на r2dbc?
Выгода такая же, как от перехода с обычного стека на реактивный. Если в приложении хоть что-то не реактивное, то все преимущества пропадают. А тем более, если это самый нижний слой, откуда поток данных начинается. Так что без перехода с блокирующего jdbc на что-то неблокирующее смысла не вижу использовать реактивщину. Ибо асинхронный поток данных будет блокироваться в самых неподходящих местах, останавливая всю асинхронную цепочку бизнес логики
Но ведь бд, пусть посередине есть обертки, является синхронным объектом. Даже если эти обертки дают псевдоасинхронность. Псевдо, потому что традиционная бд синхронна.
А если вспомнить, что у любой БД ресурсы ограничены, и количество сессий к БД тоже ограничено, то получаем что с одной стороны можно под нереактивное взаимодействие с БД выделить отдельный блокирующий пул потоков, равный количеству сессий к БД, и пользоваться реактивностью, и нереактивностью, когда это нужно. А с другой - реактивное взаимодействие, но с разными ограничениями, типа невозможности использовать уже существующий инструмент ничего не знающий про реактивность.
Я к тому, что совершенно не обязательно съезжать полностью с традиционного jdbc, и героически побеждать клубок проблем, вызванных переходом на r2dbc.
Я к такой мысли тоже приходил, хотел уже плюнуть на эти реактивные библиотеки и шедулить выполнение запросов вручную, как это делается под реактинвым капотом, но мне показалось это очень трудоемко и создание велосипеда. Но идея значит не такая уж плохая, если к ней пришел не только я. Спасибо
Согласен с тем, что вваливаться в переход на реактивный драйвер к БД чаще всего необязательно, но для полноты картины замечу, что это может быть оправданно, если узким горлышком приложения оказыватся не БД (с её ограниченными, но большими ресурсами), а Java-часть с её потенциально огромным числом далеко не бесплатных потоков. Добавление блокирующего пула в таком случае только усугубит ситуацию, поэтому имеет смысл посмотреть в сторону реактивного подхода, хоть это и весьма тернистый путь. Надеюсь, никто из нас в такой ситуации не окажется.
Нам onScheduleHook вообще не хватило. Логгинг от R2DBC идёт без MDC, если использовать только его. Ультимативное решение в итоге такое: https://www.novatec-gmbh.de/en/blog/how-can-the-mdc-context-be-used-in-the-reactive-spring-applications/ Требуется Hooks.onEachOperator и завернуть все publisher, кто не Fuseable.ScalarCallable
Уж+ёж: реактивные компоненты в сервлетном окружении (1/3)