 |
|
| オープンソースJ2EE APサーバ JBossの可能性 |
第５回：JBossの固有機能
著者：ダイテックＣ＆Ｄ 高橋 康弘 2005/5/27
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| シリアライゼーションを低減させる
|
クラスタ構成の場合のシリアライゼーション対象は、ネットワーク上のデータ送受信、および、RDBをはじめとするデータソースに対する読み書きです。こういった状況の中でJBossCacheが取った戦略は、データソースに対する読み込みを最低（キャッシュにデータが存在しない場合の最初の1回だけ）にすることで、ネットワークに関するシリアライゼーションによるパフォーマンス・ロスを相殺し、願わくは、パフォーマンスをプラスにしようというものです。
JBossCacheを利用した場合の処理の流れは次のような感じです。
- あるデータをデータソースから読み取ります
- トランザクションをコミットしてデータを確定します
- その全情報（＝キャッシュ）をクラスタ上の他のノードに対してコピーします
- 次回同じデータが必要となった場合は、データソースに対してアクセスせず、各ノードが持つローカルのキャッシュを利用してトランザクションを行います
- そして2回目以降のトランザクションでは、変更のあったデータのみ他ノードへレプリケーションし、シリアライゼーションの発生を最小にします
キャッシュに対して変更が加えられた場合は、その変更をクラスタ上の他のノードに対してコピーし、再びそのキャッシュを参照する場合はローカルのキャッシュを参照するようになります。つまり、最初の1回を除いてRDBなどのデータストアを参照する必要がまったくなくなります（当然のことながら、更新はその都度発生します）。
|
| JBossCacheの特徴
|
JBossCacheの具体的な特徴を以下に挙げます。
- キャッシュをレプリケート（同期／非同期）できる
- ツリー構造をしたキャッシュである
- トランザクション／ロック（分離レベル）をコントロールできる
- キャッシュを無効化するルールを変更できる
- キャッシュを永続化（ファイルやDBに格納）することができる
- ヒット率などの統計情報が取得できる
- 通常のデータやPOJOをキャッシュできる
いくつか補足しておきますと、「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%をアスペクト指向プログラミングによってカバーするといわれています。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社ダイテックＣ＆Ｄ 高橋 康弘
入社以来Windowsを中心としたアプリケーション開発に従事。2000年頃からJavaを扱うようになり、2年ほど前からオープンソースを利用したシステム開発を開始。最近はJBoss＋オープンソースの組み合わせでWEBアプリケーション開発に携わることが多い。
資格：JBoss認定コンサルタント
|
|
|
|
|
|
