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