TerracottaのJonas Bonér氏は最近になって、最近Terracottに雇用されたGeert Bevin氏と彼が、RIFE webアプリケーションフレームワーク をどのようにクラスタリングしたかについて詳しく語った。本記事は、RIFEのような重要なアプリケーションをクラスタリングする際の幾つかの試みと同様に、RIFEの継承の実装に関する貴重な洞察を提供するものである。
Bonér s氏はまず、どのようにRIFEは継承を実装するかについて説明することから着手した。
RIFEの継承は、汎用ライブラリとして適用可能なピュアJava環境における継承をサポートすることを目的としています・・・それは、（ASMバイトコードライブラリに基づく）バイトコードのツールを使用し、可能な最も効果的な方法で実装するためにコードを生成し、クラスを再定義します。それは、Javaシリアライゼーションに頼るのではなくオブジェクトグラフをプリミティブに分解し、実行スタックに実データを格納します（Terracottaが提供するアプローチに似ています）・・・継承がツリー構造の中に結合され、別の好きな方法で実行ステップに移ることが可能になります。これにより、時間内に実際にステップを戻したり、進めたりすることが可能になり、webアプリケーション環境で使用するときに問題となるブラウザの戻るボタンの問題を解決する巧妙な方法となります。内部的には、RIFEはその継承を汎用java.util.HashMapに格納しています。
RIFEのクラスタリングにおいて最初に直面する問題は、このHashMapスレッドに安全にアクセスするということだった。初期のRIFEの実装は、性能上の理由から、スレッドを使ってマップにアクセスするだけのために設計されていた。クラスタ化展開へ向かうにあたっては、複数のJVMからの並列アクセスがあるかもしれない。
次に努力を要したのはクラスローダーに関することであった。一般的にアプリケーションサーバーやwebフレームワークの場合がそうであるように、RIFEは多くの機能のためにカスタムクラスローダーを実装する。それらは、Javaシステムクラスローダーのように型にとらわれないTerracottaには見えないのである。
Terracottaが独自にクラスローダーを定義できなければならない理由は、時間内のどの時点においても、かつ任意のクラスタノードにおいて、クラスタを越えてオブジェクトの識別を保持するために特定のクラスをロードしたクラスローダーインスタンスを読み出す手段が必要だからです。.
しかしBonér氏とBevin氏がぶつかった最大の挑戦は、RIFEテンプレートエンジンのダイナミシティをクラスタリングすることであった。RIFEは必要なら実行時にすぐさまクラスを生成するかもしれない。この情報は、クラスが作成されたノードがクラッシュし、その後のリクエストが別のノードに向けて発信される場合、複製される必要がある。HashMapと共に実装されたクラスタワイドなバイトコードリポジトリがソルーションであることが証明された。そこで、RIFEテンプレートクラスローダーは、このリポジトリを参照するように変更された。.
（原文は2007年5月30日にリリースされました）