Я создаю традиционное веб-приложение, которое выполняет операции CRUD базы данных через JDBC. И мне интересно, хорошо ли помещать операции jdbc в актеров из текущего потока обработки запросов. Я провел поиск, но не нашел руководств или примеров приложений, демонстрирующих это.
Итак, каковы минусы и плюсы? Улучшит ли эта асинхронизация пропускную способность сервера приложений (т. е. количество обрабатываемых одновременных запросов), как в nio?
Является ли размещение доступа JDBC к акторам «хорошим» или нет, во многом зависит от остальной части вашего приложения.
Большинство современных веб-приложений являются синхронными благодаря Servlet API., который лежит в основе большинства веб-фреймворков Java (и Scala). Хотя сейчас мы видим поддержку асинхронных сервлетов, эта поддержка не сработала. вверх по всем фреймворкам. Если вы не начнете с фреймворка, поддерживающего асинхронную обработку, обработка ваших запросов будет синхронной.
Что касается JDBC, JDBC является синхронным. На самом деле с этим никогда ничего не поделаешь, учитывая бремя, которое будет возложено на модификацию огромного количества реализаций драйверов JDBC, существующих в мире. Мы можем надеяться, но не задерживайте дыхание.
И сами реализации JDBC не обязательно должны быть потокобезопасными, поэтому вызов операции с соединением JDBC до завершения какой-либо другой операции с тем же соединением приведет к неопределенному поведению. И неопределенное поведение != хорошо.
Поэтому я предполагаю, что вы не увидите таких же улучшений емкости, как с NIO.
Изменить: только что обнаружил adbcj. ; API драйвера асинхронной базы данных. Это экспериментальный проект, написанный для магистерской диссертации, очень ранний, экспериментальный. Это достойный эксперимент, и я надеюсь, что он увенчается успехом. Проверьте это!
Но если вы строите асинхронную систему на основе акторов, мне очень нравится идея иметь доступ к данным или репозиторий акторов, во многом так же, как у вас доступ к данным или репозиторий в многоуровневой объектно-ориентированной архитектуре.
Актеры гарантируют, что сообщения обрабатываются по одному, что идеально подходит для доступа к одному соединению JDBC. (Одно предостережение: большинство пулов соединений по умолчанию выдают соединение на поток, что не очень хорошо работает с акторами. Вместо этого вам нужно убедиться, что вы используете соединение на актор. То же самое верно. для управления транзакциями.)
Это позволяет вам обращаться с базой данных как с асинхронной удаленной системой, как мы должны были обращаться с ней все это время. Это также означает, что результаты ваших субъектов доступа к данным/репозитория являются будущими, которые можно составлять. Это упрощает координацию доступа к данным с другими асинхронными действиями.
Итак, это хорошо? Возможно, если он вписывается в архитектуру остальной части вашей системы. Улучшит ли это емкость? Это будет зависеть от вашей общей системы, но это звучит как очень достойный эксперимент.
