シリアライゼーションを低減させる

シリアライゼーションを低減させる

クラスタ構成の場合のシリアライゼーション対象は、ネットワーク上のデータ送受信、および、RDBをはじめとするデータソースに対する読み書きです。こういった状況の中でJBossCacheが取った戦略は、データソースに対する読み込みを最低（キャッシュにデータが存在しない場合の最初の1回だけ）にすることで、ネットワークに関するシリアライゼーションによるパフォーマンス・ロスを相殺し、願わくは、パフォーマンスをプラスにしようというものです。

JBossCacheを利用した場合の処理の流れは次のような感じです。

キャッシュに対して変更が加えられた場合は、その変更をクラスタ上の他のノードに対してコピーし、再びそのキャッシュを参照する場合は ローカルのキャッシュを参照するようになります。つまり、最初の1回を除いてRDBなどのデータストアを参照する必要がまったくなくなります（当然のことながら、更新はその都度発生します）。

JBossCacheの特徴

JBossCacheの具体的な特徴を以下に挙げます。

いくつか補足しておきますと、「5.キャッシュを永続化することができる」というのは、JavaのオブジェクトをそのままファイルやDBに格納できることを意味します。簡易的なオブジェクト指向DBのような使い方が可能となります。また、JBossCacheはSleepyCat社（注3）製のBerkrey DB Java Editionに対応しており、Javaオブジェクトの永続化に対して高いパフォーマンスと信頼性を付け加えることができます。

「6.ヒット率などの統計情報が取得できる」というのは、JBossにMBeanとして組み込まれた状態の場合に利用できます。既に説明したJMXコンソール等から確認することができます。

「7.通常のデータやPOJOをキャッシュできる」については少し詳しく説明しましょう。JBossCacheには2種類のクラスがあり、それぞれ「TreeCache」、「TreeCacheAOP」と呼ばれています。TreeCacheAOPはTreeCacheのサブクラスとなっており、TreeCacheよりも機能拡張されています。

実はTreeCacheで扱うことのできるJavaオブジェクトはSerializableインターフェースを実装している必要があります。また、キャッシュの単位はオブジェクト全体になってしまいます。

これに対して、TreeCacheAOPの場合はこういった制限がありません。普通のJavaオブジェクト（POJO）をキャッシュとして利用することができますし、オブジェクトのフィールドやコレクション型に格納されている1オブジェクトだけに対して更新をかけるといったことが可能となっています。

つまり、変更のあった部分だけを自動的に検知し、非常に細かい単位でキャッシュの更新（レプリケーション）を行うことを可能としています。

TreeCacheAOPは、通常のJavaオブジェクトに対して動的かつ自動的に必要なインターフェースを実装することで、前述のような機能を実現しています。具体的には、次で説明するJBossAOPのしくみを利用して行っています。

なお、このJBossCacheは単体でも利用することができます（注4）。

JBossAOP

JBossAOPは、アスペクト指向プログラミング（Aspect Oriented Programming）に対応したフレームワークです。アスペクト指向プログラミングを簡単に説明すると、ひとつの目的を達成するためのコードが複数ソースファイルのあちこちに散らばっているのをひとつにまとめてしまおう、というものです。

具体的にはロギング等を考えるとわかり易いと思います。

デバッグ、トレース、警告などの目的でロギング用のコードはソースコードのいたる所に書かれます。この「ロギング」のソースコードを別クラスとして抽出し、その他の残りのソースコード（アプリケーションが本来目的とするビジネスロジック）から切り離します。そして、これら別々に定義されたクラスファイルを設定ファイルにより結びつけます。こうすることで、ロギングに関するコードを1ヶ所に集めて管理することができます。

アスペクト指向プログラミングは、既存のオブジェクト指向プログラミングを置き換える存在ではなく、オブジェクト指向の欠点を補うものです。一般にオブジェクト指向プログラミングによって90%がカバーされ、残りの10%をアスペクト指向プログラミングによってカバーするといわれています。