Seasar2・・・本番運用で HOT deploy できないかな・・・我侭的考察

SAStruts や Teeda を用いて開発する際は HOT deploy は本当に便利。
それは今更ここで言及する必要はないと思う。

その HOT deploy を本番運用でも利用できないものかな。
LL のアプリケーションのように。
こう考えるのは三つの理由から。
一つは「アプリケーションを止められない」というビジネス的な都合。
そして「バグ修正や機能追加のモジュール入れ替えなどの複雑で面倒な作業をしたくないし、その方法や実施順序なんか考えたくもない」というのが二つ目。

でも

ONDEMAND deployだと、リクエストで必要なコンポーネントしかデプロイされないので、コンポーネントの数がいくら増えても平気です。
・・・
Disposableは、HOT deployを実現するためのキークラスです。Disposable#disponse()は、HOT deployのときには、リクエストの最後、COOL deploy(HOT deployじゃないもの)のときには、アプリケーションが終了するタイミングで呼び出されます。

このdisposeメソッドで、キャッシュしているメタデータを開放するようにしてあげれば、HOT deployに対応できるだけでなく、COOL deployのときは、キャッシュが利くので、パフォーマンスが劣化しません。

オンデマンドデプロイのすすめ - yvsu pron. yas

こう書かれているということはどうやら
クラスや設定ファイルなどのリソースの変更を検知して HOT deploy を実行しているのではなく、リクエストの終了時に毎回メタデータを開放し、次のリクエストが来た時にまた必要になるクラスをデプロイするということを繰り返す
という仕組みになっているみたい。
これではやはりパフォーマンスが問題になって本番運用での利用は無理か。
じゃあ、リソースの変更を動的に検知して必要な部分だけ HOT deploy するか。
HOT deploy されるリソースがクラスだとして、そのオブジェクトがステートレスで、また他のステートフルなオブジェクトの状態に関係しない前提であれば可能かな。
でもどうやって変更を検知するか。
その検知するオーバーヘッドとメタデータを部分的に作り直すコストはどの程度で本番運用で目をつぶれるか。
そしてバイナリ互換性の問題。
バイナリ互換性が壊れるクラスを走査してその場でコンパイルしなおしたりする必要が出てくる。
そりゃ大変だから全部コンパイルし直した方がマシだよってんで、バイナリ互換性を維持するように開発者にお願いして実施してもらうようなルールを作る。
こんなんでは面倒な作業はしたくないって言ってたのに、元も子もない。

あー課題山積。
・・・やはり儚い希望ですかね。静的コンパイル言語 Java でこんな話。
id:higayasuo さんはどう考えるだろう。実現可能性はありますかね。

そんなこと考えずに、PHP でも Ruby でも LL を初めから使えば良いじゃないかと叱られそうだけど、どうにもやっぱり Java が好きなもんで。
『「Java は・・・ができない」という声を聞くと少しイラっとする自分がいるんですよ』というのが三つ目の理由です。
悔しいですっ！！