ステートフルの光と影

dev

Java開発を楽しみ、プログラミングに誇りを持つ (1/2) - ＠IT
「“ステートフル”なら不要なWebプログラミングを減らせる」というタイトルで、最近台頭しつつあるステートフルなWebアプリケーションフレームワークについてのヨシオリ氏の講演のレポートがあります。具体的な例として、JBoss SeamとWicketが紹介されたようです。
私も、昔は「Seamなんて今さら・・・」と考えていたのですが、SeamがServletのステート管理をさらに細分化していることを知り、認識を改めた記憶があります。
考えてみれば、ステート管理を行う以上はステートマシンの実装が必要であり、HttpSessionの問題はステートをユーザー毎に1インスタンスしか持てないことが根本的な問題だったわけです。それを毎回作り込みで対応するのはアホな話ですわな。
というわけで、ステートフルフレームワークは今後増えていくことでしょう。実際、Seam以外にもSpring Web Flowという実装例もあります。こっちはかなり本格的にステートマシンを実装してますよ。（本格的すぎて敷居が高いという方には、Grails Web Flowがおすすめです。）
1つ注意すべき点として、ヨシオリ氏も指摘している通り、

　「デメリットとしては、一から学習する必要があることやほかの選択肢が少ないこと、HTTPsessionを多く使うのでサーバ側にメモリの負担が掛かることなどがあります。従来、HTTPsessionは多く使うべきではないといわれてきました。メモリの問題があるからです。しかし、HTTPsessionのためのコードを書くコストや、脆弱性を考慮するなど保守のコストを考えたら、以前に比べ比較的安価になってきたメモリを増やす方がコストは掛からないと思います」

JavaVMのヒープを圧迫することが問題ですね。（開発生産性とのトレードオフなのですが。）
ヒープという奴は厄介でして、物理メモリが多いからといって単純に増やせば良いというものでもないのです。例えば、

  • ヒープを増やすとGCのコストが大きくなる(特にFullGC)
  • 64bitVMを使うと、一般には32bitVMよりメモリ消費が増える(最小単位が64bitになるので)

という弊害があります。
解決策の一つは、グリッド技術などを利用してVMをスケールアウトすることです。特に、ステートのようなものはIDで分割できるので、グリッドが適用しやすいと思います。