Javaでデータベースアクセスと言えば、JDBCを使うのが一般的です。これは同期処理が前提です。
昨今の非同期処理の人気ぶりから、JDBCも非同期対応されているでしょ、と考えがちですが、なぜか対応されていません。 いや、一時期ORACLEで対応する動き(ADBA)があったのですが、プロジェクトは中止になってしまいました。
なんでも、JDBCで非同期化する一番の目的は、スレッドを減らしてサーバの負荷を減らし、スケールしやすくする為。今進行中のProject Loomがプログラム修正の負荷がほとんど無く解決してくれそうだから、別にわざわざ非同期アクセスは対応しなくていいでしょ、ということのようです。（私の英語力ではこんな感じに捉えました）
JDBCに依存するライブラリやプロダクトは相当あり、Javaコミュニティの対応が進むかどうかということ、ADBAがリリースされても普及に時間がかかることも一因だと思います。
ですが、Project Loomはいつまでたっても正式リリースされる気配がありません。いつ？みたいな。
しかし、私は考えました。
非同期処理にする目的は何か？それはWebサイトにおいて多くのクライアントからの接続を少ないサーバリソースで扱えるようにするため。
ですが、結局WebサービスなんてRDBがボトルネックになることが殆どで、多くの接続を処理するにはRDBにアクセスしたら負けです。 ということは、RDBに非同期アクセスしても、結局RDBがボトルネックになるので、今までのよく出来たライブラリを捨てて対応する価値あるのだろうか？と。
つまり、RDBは使いこそすれ、その構造や機能面から速度アップには限界があるので、全体のパフォーマンスアップのためにはキャッシュをうまく使う設計にならざるを得ません。 なので、パフォーマンス向上目的にRDBアクセスを非同期にすることはそれほど意味はないのではないか。他のキャッシュサーバ使えば非同期アクセスできるので、そちらへアクセスを逃がせばよいだけです。
アクセスの多くないサイト（同時に数十とか）は別に苦労して非同期プログラミングしなくても、スレッド生成して同期プログラミングしてれば良い。 特にLinuxのスレッドは言われているほどコストのある処理ではなく、それこそ同時に数千から数万アクセスがあるようなサイトでなければ、RDBの処理コストのほうが遥かに問題です。
とうことで、RDBの非同期アクセスライブラリが普及するのを待つのではなく、JDBCとそれベースの優秀なライブラリ(Hybanate/JPA/MyBatisとか）を使ってアクセスして、あとはとにかくキャッシュを使ってパフォーマンスを上げることを考えたほうがより現実的、という結論に行き着いたのでした。
最後に、これは単に私の考えを整理するために書いているおり、もっと違う考えあるよん、というのも当然アリだと思ってます。後で考え変わってるかもしれませんので、そのときはまたこのブログに書かせていただきます。今頃この考えに落ち着いたのか、というのはあります。前から分かってはいたのですが、モヤモヤしていたので文書に書いてみたということです。
