Ответ 1

Можно ли использовать Hibernate и Mysql с ReactiveCrudRepository вместо CrudRepository?

TL; DR:

Не с Hibernate и MySQL, но с R2DBC и Postgres, Microsoft SQL Server или H2. Взгляните на Spring Data R2DBC.

Длинная версия

Почему не JPA?

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

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

Почему не JDBC?

Таким образом, мы должны смотреть на технологический уровень ниже JPA: JDBC. Но JDBC все еще блокирует: вы отправляете оператор SQL в свою базу данных, а затем JDBC будет блокировать, пока не получите результат. И снова это идет вразрез с идеей реактивного: никогда не блокируйте. Можно было бы обернуть это в пул потоков, чтобы смягчить это до некоторой степени, но это скорее обходной путь, чем решение.

Почему R2DBC?

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

Некоторое время команда Spring Data надеялась, что ADBA восполнит этот пробел. Но обсуждения в списке рассылки прояснили, что ADBA не стремится к реактивному, а только к асинхронному. Опять же не то, что нам нужно для реактивной абстракции хранилища.

Итак, в начале 2018 года разные люди, живущие на перекрестке или реактивном и реляционном, решили, что нам нужен стандарт для реактивного доступа к базе данных.

R2DBC (R eactive R elational D atabase Д оступ) является предложение такого стандарта. Надежда состоит в том, что это либо поможет убедить Oracle перевести ADBA на реактивный подход, либо, если этого не произойдет, станет самим стандартом.

И уже при наличии трех реализаций шансы на второй вариант выглядят многообещающе.

Сам R2DBC в основном является SPI, то есть API, который должен быть реализован поставщиками баз данных. SPI разработан таким образом, чтобы предъявлять минимальные требования к исполнителям. Но это также делает R2DBC несколько громоздким в использовании. Идея состоит в том, что другие библиотеки будут наращивать и создавать библиотеки, разработанные для удобства использования поверх этого SPI, как это произошло с JDBC.

Spring Data R2DBC

Spring Data R2DBC является одной из таких библиотек, и она предлагает то, что вы просили: поддержку ReactiveCrudRepository хотя она не зависит от JPA/Hibernate и пока не поддерживает MySQL.

Состояние проектов

Как R2DBC, так и Spring Data R2DBC еще не были выпущены в рабочей версии, и для их получения потребуется не менее нескольких месяцев.

Spring Data R2DBC только что выпустил первый рубеж. См. Статью выпуска для его текущих возможностей.

R2DBC находится на 6-м этапе. См. Статью выпуска для деталей.

См. Также этот ответ: Почему Spring не предоставляет реактивных (неблокирующих) клиентов для реляционных баз данных?

Оригинальный ответ в качестве ссылки для археологов:

На данный момент (январь 2017 г.) это невозможно.

В настоящее время актуальным релизом для реактивной части Spring Data является Spring Data Kay M1 (можно проверить, есть ли более новая версия, доступная на домашней странице проекта)

И сообщение в блоге от команды Spring Data об этом выпуске и, в частности, о его реактивных частях начинается с (выделено мной):

Spring Data Kay M1 является первым выпуском, который поставляется с поддержкой реактивного доступа к данным. Его первоначальный набор поддерживаемых магазинов - MongoDB, Apache Cassandra и Redis - уже все поставляет реактивные драйверы, что делает их весьма естественными кандидатами на такой прототип.

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

Можно реализовать ReactiveCrudRepository с использованием JPA или JDBC и делегировать работу пулу потоков. Это обеспечило бы асинхронный API снаружи, но все равно потребляло бы ресурсы для потоков и блокировало бы независимый доступ к данным, так что была бы реализована лишь малая часть преимуществ реактивного подхода.

Ответ 2

Согласно цитате из предыдущего ответа

Можно реализовать ReactiveCrudRepository с использованием JPA или JDBC и делегировать работу пулу потоков. Это обеспечило бы асинхронный API снаружи, но все равно будет потреблять ресурсы для потоков и блокировать независимые доступы к данным, поэтому только небольшая часть преимуществ реактивного подхода будет реализована.

Джеймс Уорд утверждает, что он может быть неблокирующим. Я имею в виду, что я спросил его:

Да, хорошо, но не ScalikeJDBC-Async делает то же самое? просто введите запрос запроса в другой пул потоков?

и он ответил

Нет, потому что ScalalikeJDBC-Async использует https://github.com/mauricio... который фактически является неблокирующим (NIO) драйвером базы данных JDBCish.

источник

Итак, вы можете реагировать, заменив данные hibernate + spring на postgresql-async (должен работать с mysql).