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