管理設定ガイド
JBoss Enterprise Application Platform 5 向け
エディッション 5.1.2
概要
本書の範囲
第1章 はじめに リンクのコピーリンクがクリップボードにコピーされました!
- EJB3
- ステートフルセッション Bean
- ステートレスセッション Bean
- JPA (Hibernate 検証あり)
- JSF
- Facelets
- Ajax4JSF
- Seam
- JBoss Enterprise Application Platform 5 に含まれる JBoss EJB3 は、Enterprise Java Beans (EJB) 仕様の最新バージョンを実装します。EJB 3.0 は EJB 仕様が大幅に改良、簡素化されています。EJB 3.0 の目標は、開発の簡素化やテスト駆動型アプローチの推進を図るとともに、複雑な EJB API に対するコード化ではなくPOJO (Plain Old Java Object) の書き込みに焦点を置いています。
- JBoss Messaging は、 JBoss Enterprise Application Platform 5 のデフォルトのメッセージプロバイダーとして提供される高パフォーマンス JMS プロバイダーです。JBoss ESB インフラストラクチャーのバックボーンでもあります。 JBoss Messaging は、 JBoss Enterprise Application Platform 4.2 のデフォルトの JMS プロバイダーである JBossMQ を完全に書き直したものです。
- JBoss Cache は、従来のツリー構造のノードベースキャッシュと、 PojoCache の 2 種類のキャッシュを提供します。PojoCache はインメモリでレプリケーション型のトランザクションキャッシュシステムで、レプリケーションや永続性アスペクトのユーザー管理をアクティブに行わなくてもユーザーが簡単な POJO を透過的に操作できるようにします。
- JBossWS 3.x は、 Java EE 互換 Web サービス JAXWS-2.x を提供する JBoss Enterprise Application Platform 5 の Web サービススタックです。
- JBoss Transactions は、 JBoss Enterprise Application Platform 5 のデフォルトのトランザクションマネージャーです。JBoss Transactions は業界で定評のある技術を基盤とし、分散トランザクションのリーダーとして 18 年の実績を持っています。JBoss Transactions は最も相互操作性に優れた実装の 1 つです。
- JBoss Web は JBoss Enterprise Application Platform 5 の Web コンテナーで、APR (Apache Portable Runtime) と Tomcat ネイティブ技術を含む Apache Tomcat を基盤とした実装となっており、Apache Http サーバー以上のパフォーマンス特性やスケーラビリティを実現します。
1.1. JBoss Enterprise Application Platform ユースケース リンクのコピーリンクがクリップボードにコピーされました!
- 99% の Web アプリケーションがデータベースを活用している場合
- クラスター化される可能性の高いミッションクリティカルな Web アプリケーション
- JSP/サーブレットを持つ簡単な Web アプリケーションがTomcat 組み込みの JBoss Enterprise Application Platform にアップグレードされる場合
- JSP/ サーブレットを持ち、 Struts、 Java Server Faces、 Cocoon、 Tapestry、 Spring、 Expresso、 Avalon、 Turbine などの Web フレームワークを使用する中級ウェブアプリケーション。
- JSP/サーブレット、 SEAM、 EJB (Enterprise Java Bean)、 JMS (Java Messaging)、 キャッシングなどを持つ複雑な Web アプリケーション
- アプリケーション間共通のミドルウェア (JMS、Corba、JMX など)
パート I. JBoss Enterprise Application Platform インフラストラクチャー リンクのコピーリンクがクリップボードにコピーされました!
第2章 JBoss Enterprise Application Platform 5 アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
-resteasy - RESTEasy - a portable implementation of JSR-311 JAX-RS Specification |-- embedded-lib |-- lib |-- resteasy-jaxrs.war
-resteasy - RESTEasy - a portable implementation of JSR-311 JAX-RS Specification
|-- embedded-lib
|-- lib
|-- resteasy-jaxrs.war
2.1. JBoss Enterprise Application Platform のブートストラップ リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.system.server.Server implementation は org.jboss.bootstrap.microcontainer.ServerImpl です。 この実装はカーネル基本ブートストラップの拡張で、BasicXMLDeployer を使用して {jboss.server.config.url}/bootstrap.xml 記述子にて宣言されたブートストラップ beanから MC をブートします。 また、 ServerImpl レジスターは、 org.jboss.bootstrap.spi.Bootstrap インターフェースを実装する Bean のコールバックをインストールします。 bootstrap/profile*.xml 設定には、 Bootstrap インターフェースを実装する ProfileServiceBootstrap Bean が含まれます。
org.jboss.system.server.profileservice.ProfileServiceBootstrapは、org.jboss.bootstrap.spi.Bootstrap インターフェースの実装で現在のプロファイルに紐付けられたデプロイメントをロードします。PROFILE はロードされたプロファイルの名前で、 server -c コマンドライン引数に対応します。 デフォルトの PROFILE は defaultです。
2.2. ホットデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
ProfileService に関連する Profile 実装によって制御されます。 deploy/hdscanner-jboss-beans.xml よりデプロイされた HDScanner Bean はアプリケーションディレクトリ内容の変更についてプロファイルサービスをクエリし、 更新された内容を再デプロイします。 その後、 削除された内容をアンデプロイし、 ProfileService より新しいデプロイメント内容を現在のプロフィールへ追加します。
- デプロイメントから
hdscanner-jboss-beans.xmlファイルを削除します。 hdscanner-jboss-beans.xmlファイルを編集し、scanEnabled属性をfalseへ変更します。
hdscanner-jboss-beans.xml ファイルを抜粋しています。
パート II. JBoss Enterprise Application Platform 5 の設定 リンクのコピーリンクがクリップボードにコピーされました!
第3章 ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
-b [IP-ADDRESS]
|
アプリケーションサーバーのバインド先のアドレスを指定します。指定されていない場合は、アプリケーションサーバーは全アドレスにバインドします。
|
-u [IP-ADDRESS]
|
UDPマルチキャストアドレス(オプション)。指定されていない場合はTCPを利用します。
|
-m [MULTICAST_PORT_ADDRESS]
|
UDPマルチキャストポート。JGroups のみが使用します。
|
3.1. IPv6 のサポート リンクのコピーリンクがクリップボードにコピーされました!
第4章 EJB3 サービスと Enterprise Application リンクのコピーリンクがクリップボードにコピーされました!
4.1. セッション bean リンクのコピーリンクがクリップボードにコピーされました!
- Bean が
JBOSS_DIST/default/deployにあるスタンドアローンの JAR ファイルにデプロイされた場合、Bean はローカルの JNDI 名MyBean/local経由でアクセス可能です。ここでは、先ほど示したように、MyBeanは bean の実装クラス名です。JBoss AS では Local の JNDI は、java:comp/env/を起点とする JNDI 名となります。 - Bean を含む JAR ファイルが EAR ファイルにパッケージされている場合、Bean に対するローカルの JNDI 名は
myapp/MyBean/localです。このmyappはEAR アーカイブファイルのルート名となっています (例:myapp.ear。EJB3 bean の EAR パッケージについては本書で後述されていますので参照してください)。
@Remote のアノテーションがついており、デプロイされているサーバーの外から Bean にアクセスする場合は、もちろん、local を remote に変更するべきです。以下は、myapp.ear にパッケージされたWeb アプリケーションで MBean bean の参照を取得し、管理メソッドを呼び出すためのコードスニペットです (例:サーブレットあるいは JSF バッキング bean)。
@LocalBinding アノテーション を使い Bean に独自の JNDI バインディングを指定することが可能です。JNDI バインディングは常に、java:comp/env/ スペースの下では Local となります。例えば、以下の bean クラス定義は、java:comp/env/MyService/MyOwnNameという JNDI 名の下で利用可能な bean インスタンスが返ってきます。
注記
4.2. エンティティ Bean (Java Persistence API) リンクのコピーリンクがクリップボードにコピーされました!
4.2.1. persistence.xml ファイル リンクのコピーリンクがクリップボードにコピーされました!
注記
4.2.2. 代わりのデータベースを利用 リンクのコピーリンクがクリップボードにコピーされました!
- Oracle 9i および 10g: org.hibernate.dialect.Oracle9Dialect
- Microsoft SQL Server 2005: org.hibernate.dialect.SQLServerDialect
- PostgresSQL 8.1: org.hibernate.dialect.PostgreSQLDialect
- MySQL 5.0: org.hibernate.dialect.MySQL5Dialect
- DB2 8.0: org.hibernate.dialect.DB2Dialect
- Sybase ASE 12.5: org.hibernate.dialect.SybaseDialect
4.2.3. デフォルトの Hibernate オプション リンクのコピーリンクがクリップボードにコピーされました!
JBOSS_DIST/server/default/deploy/ejb3.deployer/MEAT-INF/persistence.properties ファイルで指定されます。以下は、JBoss AS 4.2 に同梱されているpersistence.properties ファイルです。コメントアウトされたオプションに注意してください。このファイルでは、persistence.xml ファイルで利用可能なプロパティにどのようなものがあるか、簡単に提示しています。
4.3. メッセージ駆動型 bean リンクのコピーリンクがクリップボードにコピーされました!
onMessage() メソッドを呼び出し、このメソッドをメッセージ内で渡し処理を行います。bean クラスは @MessageDriven アノテーションで JMS キューを指定します。このキューはローカルの JNDI java:comp/env/ 名前空間に登録されます。
4.4. EJB3 サービスのパッケージとデプロイ リンクのコピーリンクがクリップボードにコピーされました!
4.4.1. EJB3 JAR のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
JBOSS_DIST/server/default/deploy/ ディレクトリに置くと、自動的にサーバーがピックアップし処理を行います。JAR ファイルに定義されている EJB3 bean はすべて、MyBean/local など JNDI 名を使ってサーバーの内部あるいは外部にデプロイされている他のアプリケーションにて利用できるようになります。この MyBean は、セッション bean の実装クラス名です。このデプロイメントは、JBOSS_DIST/server/default/ejb3.deployer/ の JBoss EJB3 デプロイヤーを使い行われます。デフォルトの EJB3 エンティティマネージャーを設定する際に前述した、META-INF/persistence.properties ファイルは、EJB3 デプロイヤーの中に置かれています。
4.4.2. EJB3 JAR で EAR をデプロイ リンクのコピーリンクがクリップボードにコピーされました!
第5章 ロギング リンクのコピーリンクがクリップボードにコピーされました!
5.1. ロギングのデフォルト リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/conf/jboss-log4j.xml の配備記述子からロードされます。log4j は、アペンダー を使いロギングの動作を制御します。アペンダーは情報をどこにログするか、どのようにログするか指示を出します。jboss-log4j.xml ファイルには、FILE、CONSOLE、SMTPなど、多くのサンプルアペンダーが含まれています。
| 設定オプション | 詳細 |
|---|---|
appender
|
主なアペンダー。名前、実装クラスを提供します。
|
errorHandler
|
特にアペンダーが何らかの理由でログを記述できない場合に、外部クラスを委譲し、ロガーに渡される例外を処理します。
|
param
|
アペンダータイプ固有のオプション。この例では、 <param> はファイル名でFILE appender のログを格納します。
|
layout
|
ロギングのフォーマットを制御。これを微調整することで、ご利用になりたいログ構文解析ソフトウェアと連携させます。
|
例5.1 サンプルのアペンダー
5.2. コンポーネント固有のロギング リンクのコピーリンクがクリップボードにコピーされました!
5.2.1. Hibernate でのSQLロギング リンクのコピーリンクがクリップボードにコピーされました!
SessionFactory sf = new Configuration()
.setProperty("hibernate.show_sql", "true")
// ...
.buildSessionFactory();
SessionFactory sf = new Configuration()
.setProperty("hibernate.show_sql", "true")
// ...
.buildSessionFactory();
log4j.logger.org.hibernate.SQL=DEBUG, SQL_APPENDER log4j.additivity.org.hibernate.SQL=false
log4j.logger.org.hibernate.SQL=DEBUG, SQL_APPENDER
log4j.additivity.org.hibernate.SQL=false
additivity オプションは、これらのログメッセージが親ハンドラーにも反映されるかどうかを制御しますが、このオプションは任意です。
5.2.2. トランザクションサービスのロギング リンクのコピーリンクがクリップボードにコピーされました!
jbossjta-properties.xml にある com.arjuna.common.util.logger property の値をオーバーライドし、log4j_releveler ロガーを強制的に利用します。トランザクションコードの INFO レベルのメッセージは、DEBUG メッセージのような動作をします。そのため、フィルターレベルが DEBUG の場合、これらのメッセージはログファイルにのみ表示されます。その他のログメッセージはすべて通常通りの動作となっています。
第6章 デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/default/deploy ディレクトリにコピーします。default は all や minimal などの他のサーバープロファイルに置き換えることができます (サーバープロファイルについては後ほど説明します)。JBoss Enterprise Application Platform は常に deploy ディレクトリをスキャンし、 新しいアプリケーションや既存アプリケーションへの変更を検知します。これにより、 JBoss Enterprise Application Platform を実行したままアプリケーションのホットデプロイメントをオンザフライで実行できます。
6.1. デプロイ可能なアプリケーションのタイプ リンクのコピーリンクがクリップボードにコピーされました!
- WAR
- WAR アプリケーションアーカイブ (例、 myapp.war) は JAR ファイル内に Java EE Web アプリケーションをパッケージングします。これには、 サーブレットクラス、 ビューページ、 ライブラリ、さらには
web.xml、faces-config.xml、jboss-web.xmlといった、WEB-INF の配備記述子が含まれます。 - EAR
- WAR アプリケーションアーカイブ (例、 myapp.war) は JAR ファイル内に Java EE 企業向けアプリケーションをパッケージングします。 通常、Web モジュールの WAR ファイル、 EJB モジュールの JAR ファイル、 application.xml や jboss-app.xml などの META-INF 配備記述子が含まれます。
注記
EJB3 仕様に従い、永続ユニットがEAR ファイルの外部にあり、bean がこの永続ユニットをEAR内に投入しようとすると、EARへの永続ユニットのデプロイは失敗します。この仕様にあわせ、EARファイル内にパッケージされた永続ユニットをデプロイする必要があります。しかし、JBoss EAP 永続ユニットはEAR外でも存在することはできます。この動作を可能にするには、該当の JBoss AS サーバープロファイルのdeployers/ejb3.deployer/META-INF/jpa-deployer-jboss-beans.xmlファイルにあるPersistenceUnitDependencyResolverbeanのbean クラスを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このbean のデフォルト値はDynamicPersistenceUnitDependencyResolverです。このリボルバーにより、仕様に準拠した動作を指定することができ、JMX Console の MBean からこれらの動作を追加で監視可能です。仕様に準拠しないJBoss 変数を使うには、bean をInterApplicationPersistenceUnitDependencyResolverに設定します。 - JBoss Microcontainer
- JBoss Microcontainer (MC) Bean アーカイブ (拡張子は .beans や .deployer など) は、
META-INF/jboss-beans.xml記述子と共に POJO デプロイメントを JAR ファイルにパッケージ化します。 この形式は、 JBoss Enterprise Application Platform のコンポーネントデプロイヤによって頻繁に使用されます。*-jboss-beans.xmlは MC Bean 定義を使用してデプロイすることができます。 deploy ディレクトリまたは lib ディレクトリ内に適切な JAR ファイルがあれば、 スタンドアローン XML を使用して MC Bean をデプロイすることができます。 - SAR
- SAR アプリケーションアーカイブ (myservice.sar など) は、JBoss サービスを JAR ファイルにパッケージ化します。 主に、 MC Beam スタイルのデプロイメントサポートのために更新されていない JBoss Enterprise Application Platform の内部サービスによって使用されます。
*-service.xmlは MBean サービス定義を使用してデプロイすることができます。 deploy ディレクトリまたは lib ディレクトリ内に適切な JAR ファイルがあれば、 XML ファイルに指定された MBean を起動することができます。 JMS キューなど、 POJO スタイルのデプロイメントサポートのために更新されていない JBoss Enterprise Application Platform の内部サービスをデプロイする方法になります。 - DataSource
*-ds.xmlファイルは外部データベースとの接続を定義します。 これにより内部 JNDI を介して JBoss Enterprise Application Platform 内の全てのアプリケーションとサービスによるデータソースの再利用が可能になります。- HAR
- HAR ファイルは、アプリケーション用に Hibernate オブジェクトを定義します。これは SAR ファイルに似ていますが、META-INF ディレクトリにHibernate クラスとマッピングファイル、*-hibernate.xml 配備記述子を含みます。
注記
*-hibernate.xmlは、jboss-service.xmlと同じ形式を取ります。例6.1 Hibernate 配備記述子 (*-hibernate.xml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - *AR
- EJB が含まれるJAR ファイルや、 他のサービスオブジェクトを直接 JBoss Enterprise Application Platform にデプロイすることもできます。 JAR ファイルとして認識される拡張子の一覧は、
conf/bootstrap/deployers.xmlの JARStructure Bean コンストラクタセットに指定されます。
6.1.1. 展開デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
WEB-INF/web.xml、 EAR 内での META-INF/application.xml) を touch してタイムスタンプを更新します。
6.2. 標準のサーバープロファイル リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/ という名前のディレクトリに格納されます。各サーバープロファイルのディレクトリを確認すると、プロファイルに含まれるサービスやアプリケーション、ライブラリを確認することができます。
注記
$JBOSS_HOME/server/PROFILE ディレクトリの実際の内容は、サーバープロファイルのサービス実装によって異なります。また、管理層や組み込みサーバーも進化しているため、ディレクトリの内容が変更する可能性もあります。
- all
allプロファイルは、クラスタリングサポートや他のエンタープライズ拡張を提供しています。- production
- production サーバープロファイルは
allプロファイルを基に実稼働環境向けに最適化された設定を提供します。 - minimal
- 企業向けサービスを使用せずにコアサーバーコンテナを起動します。
minimalサーバープロファイルは必要なサービスのみを含むJBoss Enterprise Application Platform をカスタマイズ構築する際に基盤として使います。 - default
- default サーバープロファイルはアプリケーション開発者が最も頻繁に使用するプロファイルで、標準の Java EE 5.0 プログラミング API (Annotations、 JPA、 EJB3 など) をサポートします。
注記
プロファイルがコマンドラインあるいは設定ファイルで指定されていない場合、defaultサーバープロファイルを使います。 - standard
- standard サーバープロファイルは Java EE に準拠するようテストされたプロファイルです 。既存設定との主な違いは、 デフォルトでコールバイバリュー (call-by-value) とデプロイメント分離が有効になっていることと、
rmiiiopとjuddi(all 設定より取得) のサポートが有効になっていることです。 - web
- web サーバープロファイルは、JBoss Web 向けに実験的に作成された軽量設定で、JavaEE 6 web サーバープロファイルの開発に従っていきます。
servlet/jspコンテナ以外は JTA/JCA と JPA のサポートを提供します。HTTP ポートからのみサーバーへのアクセスが許可されるよう制限されています。 この設定は JavaEE 認定の設定ではなく、今後のリリースで変更になる可能性が高いことにご留意ください。
6.2.1. プロファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
run.sh -c profile のように -c パラメーターで必要なプロファイルを指定します。例えば、Red Hat Enterprise Linux ではrun.sh -c all 、Microsoft Windows では run.bat -c all コマンドがall サーバープロファイルでサーバーを起動します。
6.3. コンテキストルート リンクのコピーリンクがクリップボードにコピーされました!
hello ディレクトリを含む、application.war アーカイブをデプロイした場合、hello アプリケーションのコンテキストルートは、/application/home となります。
手順6.1 デフォルトのコンテキストルートを書き直し
- 新規のコンテキストルートを定義するには、新しい値を持つ context-root 要素をアプリケーションの配備記述子に追加します。
- Web アプリケーションのコンテキストアプリケーションを変更するには、context-root 要素を
jboss-web.xmlファイルに追加します。例6.2 コンテキストルートを定義した jboss-web.xml 例
<?xml version="1.0"?> <jboss-web> <context-root>/application-root</context-root> </jboss-web>
<?xml version="1.0"?> <jboss-web> <context-root>/application-root</context-root> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow localhost のアプリケーション用 URL アドレスはです。http://localhost:8080/application-root
- サーブレットのコンテキストルートを変更するには、
web.xmlファイルの url-pattern 要素を変更します。例6.3 コンテキストルートを定義した web.xml 例
<?xml version="1.0"?> <servlet-mapping> <servlet-name>MapRenderer</servlet-name> <url-pattern>/servlet-root</url-pattern> </servlet-mapping>
<?xml version="1.0"?> <servlet-mapping> <servlet-name>MapRenderer</servlet-name> <url-pattern>/servlet-root</url-pattern> </servlet-mapping>Copy to Clipboard Copied! Toggle word wrap Toggle overflow localhost のサーブレット用 URL アドレスはです。http://localhost:8080/application-root/servlet-root
- REWRITE_CONTEXT_CHECK 変数が
falseに設定されているサーバーを起動するには、run.sh -Dorg.apache.catalina.connector.Response.REWRITE_CONTEXT_CHECK=falseコマンドを実行します。
第7章 マイクロコンテナー リンクのコピーリンクがクリップボードにコピーされました!
注記
第8章 JNDI ネーミングサービス リンクのコピーリンクがクリップボードにコピーされました!
queue/IncomingOrders という名称のメッセージキューに接続するだけで、キューの設定詳細に関しては考慮する必要がありません。
ProductCatalog セッション bean をルックアップできる必要があります。大規模なクラスター化サービス、ローカルリソース、あるいはアプリケーションコンポーネントのいずれかが必要かによって、JNDI ネーミングサービスは、コードが名前別にシステム内のオブジェクトを検索できるよう接着点としての機能を提供します。
8.1. JNDI の概要 リンクのコピーリンクがクリップボードにコピーされました!
javax.naming パッケージで、この中にはインターフェースが5個、クラスが10個、例外が数個含まれています。主なクラス1つ (InitialContext) と、インターフェース2つ (Context および Name) が存在します。
8.1.1. 名前 リンクのコピーリンクがクリップボードにコピーされました!
/") で区切られます。このファイルのパスは左から右の順になります。たとえば、パス名 /usr/jboss/readme.txt は、ファイルシステムの root にある usr ディレクトリ配下のjboss ディレクトリ内にある readme.txt ファイルを指します。JBoss Enterprise Application Platform のネーミングは、Unix 形式の命名空間を命名規則として採用しています。
javax.naming.Name インターフェースは、汎用名をコンポーネントの順に表します。合成名 (複数の名前空間にわたる名前) の場合も、複合名の場合も (単一階層のネーミングシステム内で利用される名前) あります。名前のコンポーネントには番号がつけられます。コンポーネント N を持つ名前のインデックスは、0 から N 未満の範囲となっています。最も重要なコンポーネントは、インデックス 0 にあります。また、空の名前にはコンポーネントがありません。
scp などの Unix コマンドで通常使われるホスト名とファイルの組み合わせなどでしょう。例えば、以下のコマンドは、localfile.txt を、 ahost.someorg.orgホストにある tmpディレクトリの remotefile.txt ファイルにコピーします。
scp localfile.txt ahost.someorg.org:/tmp/remotefile.txt
scp localfile.txt ahost.someorg.org:/tmp/remotefile.txt
ahost.someorg.org:/tmp/remotefile.txt は、DNS と Unix ファイルシステムの名前空間にわたる複合名となっています。また、複合名のコンポーネントは、ahost.someorg.org と /tmp/remotefile.txtで、コンポーネントは、ネーミングシステムの名前空間からの文字列名となっています。コンポーネントが階層名前空間から来るものであれば、このコンポーネントは、javax.naming.CompoundName クラスを使って原子パーツにさらに構文解析することができます。JNDI API は、合成名の Nameインターフェースの実装として、javax.naming.CompositeName クラスを提供します。
8.1.2. コンテキスト リンクのコピーリンクがクリップボードにコピーされました!
javax.naming.Context インターフェースは、ネーミングサービスとやりとりを行うにあたり主要なインターフェースとなっています。Context インターフェースは、名前とオブジェクトのバインディングセットを表します。全コンテキストは紐付けられた命名規則があり、それにより、コンテキストがjavax.naming.Name インスタンスで文字列名を解析する方法を決定します。名前とオブジェクトのバインディングを作成するには、Context のバインドメソッドを呼出し、名前とオブジェクトを引数として指定します。このオブジェクトは、あとでContextのロックアップメソッドを使った名前でリトリーブすることができます。通常、Context で、名前とオブジェクトのバインド、名前のアンバインド、名前とオブジェクトの全バインディングの一覧を取得する操作を行うことができます。Context にバインドするオブジェクトは、それ自体がContextタイプになり得ます。バインドされたContext オブジェクトは、バインドメソッドが呼び出されたところで Context のサブコンテキストとして参照されます。
/usrで、Unix ファイルシステムではコンテキストとなるファイルディレクトリを見てみましょう。別のファイルディレクトリを起点に指定されたファイルディレクトリはサブコンテキスト (通常サブディレクトリと呼ばれる) となります。/usr/jbossとのパス名を持つファイルディレクトリは、usrのサブコンテキストであるjbossコンテキストを指定します。別の例では、orgなどのDNSドメインはコンテキストで、別のDNS ドメインを起点に指定されたDNS ドメインはサブコンテキストの別例となっています。DNSドメインjboss.orgでは、DNS名は右から左に解析されるため、DNS ドメインjbossがorgのサブコンテキストとなります。
8.1.2.1. InitailContext を使ってコンテキストを取得 リンクのコピーリンクがクリップボードにコピーされました!
Context インターフェースの実装で行われます。したがって、使おうとしているネーミングサービスの Context を取得する方法が必要になります。javax.naming.IntialContext クラスは Context インターフェースを実装するので、 ネーミングサービスとのやりとりを開始することができます。
InitialContext を作成する場合、この環境からのプロパティを使って初期化されます。JNDI は以下のソース2つからの値を順にマージすることで、各プロパティの値を決定します。
- コンストラクターの環境パラメーターから最初に発生したプロパティ、(適切なプロパティに対して)アプレットパラメーターとシステムプロパティ
- クラスパス上にある全
jndi.propertiesリソースファイル
jndi.properties ファイルを使う方法をお勧めします。このファイルによりコードが JNDI プロバイダー固有の情報を外部に配置することができるようになるため、JNDI プロバイダーを変更してもコードの変更や再コンパイルを必要としません。
InitialContext クラスが内部で使用するContext 実装は、ランタイム時に決定されます。デフォルトポリシーは、javax.naming.spi.InitialContextFactory 実装のクラス名を含む環境プロパティ java.naming.factory.initialを使います。ご利用中のネーミングサービスプロバイダーからInitialContextFactory クラス名を取得します。
jndi.properties ファイルを提供しています。クライアントアプリケーションは、アプリケーションクラスパスにあるjndi.properties ファイルが必要となるでしょう。これらは、JBossNS JNDI 実装が必要とするプロパティです。その他のJNDI プロバイダーには、別のプロパティと値があります。
例8.1 jndi.properties ファイルの例
### JBossNS properties java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://localhost:1099 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
### JBossNS properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
8.2. JBoss Naming Service アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
javax.naming.Context インターフェースのJava ソケット/RIM ベース実装となっています。JBossNS はリモートからアクセス可能なクライアント/サーバー実装で、この実装は最適化されており、ソケットを必要とせずに、JBossNS サーバーが稼働している同じVM からアクセスすることができます。グローバルシングルトンとして利用可能なオブジェクト参照を使うことで同じVM アクセスが発生します。図8.1「JBoss Naming Service アーキテクチャーで主要なコンポーネント」 では、JBossNS 実装およびその関係において重要となるキーの一部を図解しています。
図8.1 JBoss Naming Service アーキテクチャーで主要なコンポーネント
NamingService MBeanから見ていきます。NamingService MBean は、JNDI ネーミングサービスを提供しており、J2EE テクノロジーコンポーネントで広範利用されている主要サービスです。NamingService の設定可能な属性を以下に示します。
- Port:
NamingServiceのポートをリッスンする jnp プロトコル。指定がない場合は、RMI レジストリのデフォルトポートと同じ 1099 がデフォルトになります。 - RmiPort: RMI ネーミング実装がエクスポートされるRMI ポート。指定がない場合、デフォルトは0で、利用可能なポートはどれでも利用するという意味です。
- BindAddress:
NamingServiceがリッスンする特定のアドレス。ソケットアドレスの1つに関する接続リクエストしか受け付けないjava.net.ServerSocketのマルチホームホスト上で利用可能です。 - RmiBindAddress:
NamingServiceの RIM サーバー部分がリッスンする特定のアドレスです。ソケットアドレスの1つに関する接続リクエストしか受け付けないjava.net.ServerSocketのマルチホームホスト上で利用可能です。指定されていず、BindAddressが指定されている場合、RmiBindAddressはBindAddress値にデフォルト設定されます。 - Backlog: 受信接続の表示 (接続要求) に対する最大長は
backlogパラメーターに設定します。キューがフルの状態で接続表示を受けると、その接続は拒否されます。 - clientSocketFactory: オプションのカスタム
java.rmi.server.RMIClientSocketFactory実装クラス名。指定されていない場合、デフォルトのRMIClientSocketFactoryが利用されます。 - ServerSocketFactory: オプションのカスタム
java.rmi.server.RMIServerSocketFactory実装名。指定されていない場合、デフォルトのRMIServerSocketFactoryが利用されます。 - JNPServerSocketFactory: オプションのカスタム
javax.net.ServerSocketFactory実装クラス名。JBoss Naming ServiceNamingインターフェースのダウンロードをブートストラップするために利用するServerSocketのファクトリ。指定されていない場合、javax.net.ServerSocketFactory.getDefault()メソッド値が利用されます。
java:compコンテキストへアクセスするスレッドのコンテキストクラスローダーに基づき、このコンテキストへのアクセスが隔離されるように、NamingService も java:compを作成します。こうすることで J2EE 仕様で必要なアプリケーションコンポーネントのプライベートENC を提供します。このような隔離は、javax.naming.Reference をorg.jboss.naming.ENCFactoryを使用するコンテキストにjavax.naming.ObjectFactoryとしてバインドすることで行うことができます。クライアントがjava:compやサブコンテキストのルックアップを行う場合、ENCFactory はスレッドコンテキストClassLoaderをチェックし、ClassLoader をキーとして使いマップ内でルックアップを実行します。
ENCFactory マップ内にコンテキストインスタンスが作成されクラスローダーと紐付けられます。そのため、実行中のコンポーネントスレッドに紐付いた固有のClassLoader を受け取る各コンポーネントにより、正確にアプリケーションコンポーネントのENC を隔離されるか左右されます。
NamingService はその機能をorg.jnp.server.Main MBean に委譲します。MBean が重複する理由には、JBoss Naming Service が最初はスタンドアローンの JNDI 実装として開始され、そのまま実行することができるという点が挙げられます。NamingService MBean はMain インスタンスを JBoss サーバーに埋め込むため、JBossサーバーと同じ VM とJNDI を利用しても、ソケットのオーバーヘッドは発生しません。実際は、NamingService の設定可能な属性は、JBoss Naming Service Main MBean の設定可能な属性なのです。NamingService MBean 上の属性設定は、単に NamingService 内のMain MBean にある該当属性を設定するだけです。NamingService が起動すると、包含するMain MBean を開始し JNDI のネーミングサービスを有効にします。
NamingService は、JMX detyped 呼出し操作によりNaming インターフェースの操作を公開します。これにより、任意のプロトコルに対する JMX アダプタを経由でネーミングサービスにアクセスできるようになります。HTTP が呼出し操作を使ってネーミングサービスにアクセスする方法について、一例を本章で後述します。
Main MBeanが開始されると、以下のタスクを実行します。
org.jnp.naming.NamingServiceインスタンスをインスタンス化し、これをローカルのVM サーバーインスタンスとして設定します。これは、JBoss サーバーのVM内に作成されたorg.jnp.interfaces.NamingContextインスタンスのいずれかが使用しTCP/IP でのRMI 呼出しが回避されるようにします。- 設定された
RmiPort、ClientSocketFactory、ServerSocketFactory属性を使って、NamingServerインスタンスのorg.jnp.naming.interfaces.NamingRMI インターフェースをエクスポートします。 BindAddressとPort属性により与えられたインターフェースをリッスンするソケットを作成します。- ソケットで接続を受け取るスレッドを生成します。
8.3. Naming IntialContext ファクトリ リンクのコピーリンクがクリップボードにコピーされました!
InitialContext ファクトリ実装に対応しています。
8.3.1. 標準のネーミングコンテキストファクトリ リンクのコピーリンクがクリップボードにコピーされました!
org.jnp.interfaces.NamingContextFactory実装で、このプロパティには以下が含まれます。
- java.naming.factory.initial: 最初に使うコンテキストファクトリを指定するための環境プロパティ名。プロパティの値は、最初のコンテキストを作成するファクトリクラスの完全修飾クラス名にする必要があります。これが指定されていない場合、
InitialContextオブジェクトが作成されるとjavax.naming.NoInitialContextExceptionがスローされます。 - java.naming.provider.url: クライアントが使う JBoss JNDI サービスプロバイダーの場所を指定するための環境プロパティ名。
NamingContextFactoryクラスはこの情報を使いどの JBossNS サーバーに接続するかを把握します。このプロパティの値はURL文字列としてください。JBossNSでは、URL 形式はjnp://host:port/[jndi_path]となっています。URL のjnp:の部分はプロトコルで、これは JBoss が使うソケット/RMI ベースのプロトコルを参照します。URL のjndi_pathの部分は、root コンテキストを起点としたオプションのJNDI名となっています (例:appsやapps/tmp)。ホストコンポーネント以外はすべてオプションとなっています。デフォルトのポート値が 1099 であるため、以下の例はすべて同じです。jnp://www.jboss.org:1099/www.jboss.org:1099www.jboss.org
- java.naming.factory.url.pkgs: URL コンテキストファクトリでローディングする際に使うパッケージプレフィックス一覧を指定するための環境プロパティ名。このプロパティの値はファクトリクラスのクラス名につけるプレフィックス一覧をコンマで区切るものとします。このファクトリクラスは、URL コンテキストファクトリを作成します。JBoss JNDI プロバイダーでは、これは
org.jboss.naming:org.jnp.interfacesでなければなりません。このプロパティは、JBoss JNDI プロバイダーのjnp:とjava:URL コンテキストファクトリを検索する際に必須となっています。 - jnp.socketFactory: ブートストラップソケットを作成するのに利用する
javax.net.SocketFactory実装の完全修飾クラス名。デフォルト値は、org.jnp.interfaces.TimedSocketFactoryで、TimedSocketFactoryは、接続と読み込みタイムアウトの使用に対応する単純なSocketFactory実装となっています。この2つのプロパティは以下により指定されます。 - jnp.timeout: 接続のタイムアウト(ミリ秒単位)。デフォルト値が0の場合、VM TCP/IP がタイムアウトするまで、接続が停止されます。
- jnp.sotimeout: 接続されたソケットの読み込みタイムアウト (ミリ秒単位)。デフォルト値が0の場合、読み込みが停止します。これは新しく接続されたソケットで
Socket.setSoTimeoutに渡される値となっています。
InitialContext を作成するとorg.jnp.interfaces.NamingContextFactory オブジェクトを使い今後の操作で利用されるContext インスタンスを作成します。NamingContextFactory は javax.naming.spi.InitialContextFactory インターフェースのJBossNS 実装となっており、 NamingContextFactory クラスにContextを作成が求められると、グローバル JNDI 名前空間にあるコンテキスト名とInitialContext 環境を使い org.jnp.interfaces.NamingContextインスタンスを作成します。NamingContext インスタンスが実際にJBossNS サーバーに接続するタスクを実行し、 Context インターフェースを実装しています。この環境からのContext.PROVIDER_URL 情報は、どのサーバーからNamingServer RMI 参照を取得するか示しています。
NamingContext インスタンスとNamingServer インスタンスの紐付けは、最初の Context 操作が実行される際に遅延モードで行われます。Context 操作が実行されNamingContext に紐付けられている NamingServer がない場合、その環境プロパティがContext.PROVIDER_URLを定義しているかどうか確認します。Context.PROVIDER_URL は、Context が使う予定の JBossNS サーバーのホストとポートを定義します。プロバイダ URL がある場合、NamingContext はNamingContext クラスの静的マップを確認することで、まずホストとポートの組み合わせで入力される Naming インスタンスがすでに作成されていないか確認します。ホストとポートのペアでインスタンスがすでに取得されている場合、単に既存のNaming インスタンスを使います。該当のホストとポートに対して、Naming インスタンスがすでに作成されていない場合、NamingContext はjava.net.Socketを使ってホストとポートを接続し、ソケットからjava.rmi.MarshalledObject を読み込み、get メソッドを呼び出すことでサーバーからNaming RMI スタブをリトリーブします。新しく取得したNaming インスタンスは、ホストとポートの組み合わせ配下にある NamingContext サーバーマップでキャッシュ化されます。コンテキストが紐付けられた JNDI 環境にてプロバイダー URL が指定されていない場合、NamingContext は単にMain MBean で設定された VM Naming インスタンスを使用します。
Context インターフェースの NamingContext 実装は、全操作を NamingContext に紐付けられた Naming インスタンスに委譲します。Naming インターフェースを実装する NamingServer クラスはContext ストアとして java.util.Hashtable を使用します。特定の JBossNS サーバーに対する JNDI 名はそれぞれ違っており、各 JNDI 名に固有のNamingServerが1つずつ存在します。NamingServer インスタンスを参照する時点で有効になる一時的な NamingContext インスタンスは 0 またはそれ以上存在します。NamingContext の目的は、NamingContextに渡される JNDI 名の変換を管理する Naming インターフェースアダプターに対し Context として動作することです。JNDI名は相対あるいは URL になり得るので、参照先の JBossNS サーバーのコンテキスト内で絶対名に変換される必要があります。この変換はNamingContext の主要機能となります。
8.3.2. org.jboss.naming.NamingContextFactory リンクのコピーリンクがクリップボードにコピーされました!
InitialContextFactory 実装は jnp バージョンの単純拡張で、jnp バージョンと違うのは、パブリックスレッドのローカル変数内で InitialContextFactory.getInitialContext(Hashtable env) メソッドに渡す最後の設定を格納する点です。これは、UserTransaction ファクトリなどのEJB ハンドルやその他の JNDI を検知するオブジェクトは作成された時点で効力を発揮する JNDI コンテキストを継続的に追跡しますが、この実装はこれらのEJBハンドルやその他のJNDI-sensitive オブジェクトにより利用されます。vm 境界を越えシリアル化された後でも、この環境をオブジェクトにバインドさせたい場合、org.jboss.naming.NamingContextFactoryを利用してください。現在のVM jndi.properties あるいはシステムプロパティにて定義された環境が必要な場合は、org.jnp.interfaces.NamingContextFactory のバージョンを使ってください。
8.3.3. クラスター環境でのネーミングディスカバリ リンクのコピーリンクがクリップボードにコピーされました!
Context.PROVIDER_URL 値を指定せず、クライアントが利用可能なネーミングサービスをネットワークにクエリするよう選択することができます。これは、all サーバープロファイルあるいは、org.jboss.ha.framework.server.ClusterPartition と org.jboss.ha.jndi.HANamingService がデプロイされている同等のサーバープロファイルで稼働している JBoss サーバーでのみ機能します。このディスカバリプロセスでは、ディスカバリアドレス/ポートへマルチキャストリクエストパケットを送信し、ノードからの応答を待機します。この応答は、Naming インターフェースの HA-RMI バージョンとなっています。以下の InitialContext プロパティにより、ディスカバリ設定が変わってきます。
- jnp.partitionName: クラスターパーティション名のディスカバリは制限される必要があります。複数のクラスターを持つ環境で稼働している場合、 特定のクラスターを対象にネーミングディスカバリを行いたい場合があるかもしれません。デフォルト値なし。これは、クラスターの応答はどれでも受け付けることになります。
- jnp.discoveryGroup: ディスカバリクエリの送信先マルチキャスト IP アドレス。デフォルトは、230.0.0.4。
- jnp.discoveryPort: ディスカバリクエリの送信先ポート。デフォルトは 1102。
- jnp.discoveryTimeout: ディスカバリクエリの応答待機時間 (ミリ秒単位)。デフォルト値は、5000 (5 秒)。
- jnp.disableDiscovery: ディスカバリプロセスを回避する必要がある場合にたてるフラグ。
Context.PROVIDER_URLが指定されていない場合、あるいは指定 URL に有効なネーミングサービスが見付からない場合、ディスカバリは起こります。jnp.disableDiscoveryフラグが true の場合、ディスカバリは試行されません。
8.3.4. HTTP InitialContext Factory 実装 リンクのコピーリンクがクリップボードにコピーされました!
Context インターフェースを継続利用しており、透過的な変更になります。Context インターフェース経由の操作は、(JMX 呼び出し操作を使ってリクエストを NamingService に渡す) サーブレットへの HTTP ポストに変換されます。HTTP をアクセスプロトコルとして使用する利点には、HTTP を許可する設定のプロキシやファイアウォールを通過するアクセスの他、 セキュリティをベースとした標準サーブレットロールを使って JNDI サービスへのアクセスセキュリティーを保つ機能などがあります。
org.jboss.naming.HttpNamingContextFactory をファクトリ実装として利用します。このファクトリのサポート InitialContext 環境プロパティの完全セットは以下の通りです:
- java.naming.factory.initial: 初期コンテキストファクトリを指定する環境プロパティ名。
org.jboss.naming.HttpNamingContextFactoryでなければなりません。 - java.naming.provider.url (あるいは
Context.PROVIDER_URL): これは JNDI ファクトリの HTTP URL に設定する必要があります。完全な HTTP URL は、JBoss サーブレットコンテナーの公開 URLに/invoker/JNDIFactoryを付け加えたものになるでしょう。例は以下の通りです。http://www.jboss.org:8080/invoker/JNDIFactoryhttp://www.jboss.org/invoker/JNDIFactoryhttps://www.jboss.org/invoker/JNDIFactory
最初の例は、ポート8080 を使ってサーブレットにアクセスし、2番目は標準の HTTP ポート 80 を使い、3番目はSSL 暗号化接続を使い標準の HTTPS ポート443 へアクセスします。 - java.naming.factory.url.pkgs: 全 JBoss JNDI プロバイダーに対し
org.jboss.naming:org.jnp.interfacesにしなければなりません。このプロパティは、JBoss JNDI プロバイダーのjnp:やjava:URL コンテキストファクトリの場所を検索するのに必要となります。
HttpNamingContextFactory によって返された JNDI Context 実装は、JMX バスを介して呼出しをNamingServiceへのに転送し、HTTP経由で返信をマーシャルするブリッジサーブレットに呼出しを委譲するプロキシです。このプロキシが動作するには、ブリッジサーブレットの URL は何かを把握している必要があります。この値は、JBoss Webサーバーがよく知られている公開インターフェースの場合、サーバー側ですでにバインドされている場合もあります。JBoss Web サーバーがファイヤウォールやプロキシ1つ以上を介す場合、プロキシは必要なURL はどれか把握できません。このような場合は、プロキシをクライアントVM にて設定する必要のあるシステムプロパティ値と関連付けます。HTTP 上でJNDIの操作に関する詳細情報は、「HTTP 経由で JNDI にアクセス」を参照してください。
注記
8.3.5. Login InitialContext Factory 実装 リンクのコピーリンクがクリップボードにコピーされました!
InitialContext を使うことでセキュリティ証明を渡すことができます。JAAS はバックグラウンドで使用されていますが、クライアントアプリケーションでJAAS インターフェースは明示的に利用されません。
org.jboss.security.jndi.LoginInitialContextFactoryで、このファクトリのサポートInitialContext 環境プロパティの全セットは以下の通りです。
- java.naming.factory.initial: 最初のコンテキストファクトリを指定するための環境プロパティ名。
org.jboss.security.jndi.LoginInitialContextFactoryでなければなりません。 - java.naming.provider.url:
NamingContextFactoryプロバイダー URL に設定する必要があります。LoginIntialContextは単に、既存のNamingContextFactoryの動作に JAAS ログインを追加するNamingContextFactoryのラッパーというだけのことです。 - java.naming.factory.url.pkgs: 全 JBoss JNDI プロバイダーに対し
org.jboss.naming:org.jnp.interfacesにしなければなりません。このプロパティは、JBoss JNDI プロバイダーのjnp:やjava:URL コンテキストファクトリの場所を検索するのに必要となります。 - java.naming.security.principal (あるいは
Context.SECURITY_PRINCIPAL): 認証主体。これはjava.security.Principal実装あるいは主体名を示す文字列のいずれかです。 - java.naming.security.credentials (あるいは
Context.SECURITY_CREDENTIALS):主体認証に使われる証明書。例:パスワード、セションキーなど - java.naming.security.protocol: (
Context.SECURITY_PROTOCOL) :JAAS ログインモジュール名を提供し主体や証明書の認証に使用します。
8.3.6. ORBInitialContextFactory リンクのコピーリンクがクリップボードにコピーされました!
deploy/iiop-service.xml? で設定される ORB を使用せずに JNDI で ORB を検索します。org.jboss.iiop.naming.ORBInitialContextFactory にグローバルなコンテキストファクトリを設定する必要があります。これにより ORB を JBoss の ORB に設定します。この設定は conf/jndi.properties ファイル内で行います。
ORBInitialContextFactory を利用する必要があります。
8.4. HTTP 経由の JNDI リンクのコピーリンクがクリップボードにコピーされました!
8.4.1. HTTP 経由で JNDI にアクセス リンクのコピーリンクがクリップボードにコピーされました!
http-invoker.sar により提供されており、http-invoker.sar の構造は以下の通りです。
jboss-service.xml 記述子は、HttpInvoker と HttpInvokerHA MBean を定義します。これらのサービスは、HTTP経由でJMX バスにある適切な対象の MBean へ送信されるメソッド呼出しルーティングを処理します。
http-invoker.war Web アプリケーションには、HTTP トランスポートの詳細を処理するサーブレットが含まれています。NamingFactoryServlet は、JBoss JNDIネーミングサービス javax.naming.Context 実装に対する作成リクエストを処理します。InvokerServlet は、RMI/HTTP クライアントによる呼出しを処理します。ReadOnlyAccessFilter により、JNDIネーミングサービスのセキュリティを確保し、未認証のクライアントに読み取り専用のアクセスを提供する JNDI コンテキストを作成することができるようになります。
図8.2 JNDI コンテキストに対する HTTP invoker のプロキシ/サーバーの構成
http-invoker サービスの操作について見てみましょう。図8.2「JNDI コンテキストに対する HTTP invoker のプロキシ/サーバーの構成」 で、JBoss JNDIプロキシの構造とJBoss サーバー側のhttp-invokerコンポーネントとの関係に関する論理的な見解を示しています。このプロキシは、Context.INITIAL_CONTEXT_FACTORYプロパティがorg.jboss.naming.HttpNamingContextFactoryに設定され、Context.PROVIDER_URLプロパティがNamingFactoryServletのHTTP URL に設定されているInitialContext を使い、NamingFactoryServlet から取得します。結果として出たプロキシは Context 実装を提供するorg.jnp.interfaces.NamingContext インスタンスに組み込まれます。
org.jboss.invocation.http.interfaces.HttpInvokerProxyのインスタンスで、org.jnp.interfaces.Namingインターフェースを実装します。内部的にHttpInvokerProxy は、HTTP ポスト経由で Naming インターフェースメソッド呼出しをInvokerServlet にマーシャルする invoker を含みます。InvokerServlet は、これらのポストを JMX 呼出しをNamingServiceに変換し、HTTP ポストのレスポンスにて呼出しの応答をプロキシに返します。
図8.3 設定ファイルと JNDI/HTTP コンポーネント間の関係
http-invoker.sar/META-INF/jboss-service.xml 記述子は、NamingServiceのHttpInvokerProxy を作成するHttpProxyFactory を定義します。HttpProxyFactory に対する設定が必要な属性には以下が含まれます:
- InvokerName:
conf/jboss-service.xml記述子にて定義されるNamingServiceのJMXObjectName。JBoss ディストリビューションで使用される標準設定はjboss:service=Naming。 - InvokerURL あるいは InvokerURLPrefix + InvokerURLSuffix + UseHostName:完全な HTTP URL を
InvokerURL属性を使い、InvokerServletに指定することができます。あるいは、URLのホスト名に依存しない部分を特定し、HttpProxyFactoryを入力できます。InvokerURL値の例として、http://jbosshost1.dot.com:8080/invoker/JMXInvokerServletなどが挙げられます。これは以下に分割できます。- InvokerURLPrefix: ホスト名の前につく URL のプレフィックス。通常、
http://あるいはhttps://(SSL が使われている場合) となっています。 - InvokerURLSuffix: ホスト名の後につくURL のサフィックス。これには Web サーバーのポート番号、
InvokerServletにデプロイされるパスが含まれます。例えば、InvokerURLSuffixのInvokerURLの値は、引用符なしの:8080/invoker/JMXInvokerServletとなります。ポート番号は Web コンテナサービス設定により決まります。InvokerServletへのパスは、http-invoker.sar/invoker.war/WEB-INF/web.xmlの記述子にて指定されます。 - UseHostName: 完全
InvokerURLのホスト名部分を構築する際、ホスト名をホスト IP アドレスの位置に使用するか示すフラグ。True の場合、InetAddress.getLocalHost().getHostNameメソッドが使われます。True でなければ、InetAddress.getLocalHost().getHostAddress()メソッドが利用されます。
- ExportedInterface: プロキシがクライアントに対し公開する
org.jnp.interfaces.Namingインターフェース。このプロキシの実際のクライアントは、JBoss JNDI実装のNamingContextクラスで、JBoss JNDIプロバイダーを使う場合、JNDI クライアントはInitialContextルックアップから取得します。 - JndiName: プロキシがバインドされる場合の JNDI の名前。このインターフェースが JNDI にバインドされないように、この項目はブランク/空の文字列に設定する必要があります。JNDI を使ってそれ自体をブートストラップすることはできません。これは、
NamingFactoryServletの役割になります。
http-invoker.sar/invoker.war/WEB-INF/web.xml 記述子は、初期化パラメーターと共にNamingFactoryServlet と InvokerServlet のマッピングを定義します。JNDI/HTTP に関連するNamingFactoryServletの設定は JNDIFactory のエントリで以下を定義します。
HttpProxyFactoryMBean 名をマッピングするnamingProxyMBeanの初期化パラメーター。HTTP ポストへの応答時に返すNamingプロキシを取得するために、NamingFactoryServletがこのパラメーターを利用します。デフォルトのhttp-invoker.sar/META-INF/jboss-service.xml設定は、名前がjboss:service=invoker,type=http,target=Namingとなります。- Naming プロキシ値をクエリするための
namingProxyMBean属性名を定義するプロキシ初期化パラメーター。属性名がProxyにデフォルト設定されています。 JNDIFactory設定のサーブレットマッピング。セキュリティー保護されていないマッピングのデフォルト設定は/JNDIFactory/*となっています。これは、http-invoker.sar/invoker.warのコンテキスト root を起点とした相対パスでデフォルトでは、.warのサフィックスを取ったWAR名となっています。
InvokerServlet 設定は JMXInvokerServlet で以下を定義します。
InvokerServletのサーブレットマッピング。セキュリティ保護されていないマッピングのデフォルト設定は/JMXInvokerServlet/*で、これは、http-invoker.sar/invoker.warのコンテキスト root を起点とした相対パスでデフォルトでは、.warのサフィックスを取ったWAR名となっています。
8.4.2. HTTPS でJNDI にアクセス リンクのコピーリンクがクリップボードにコピーされました!
HttpProxyFactory 設定構成も提供しています。次の例ではこの設定を提供するためのサンプル例をインストールする http-invoker.sarjboss-service.xml 記述子のセクションを示します。標準 HTTP 設定に相対的に変更されたものは InvokerURLPrefix および InvokerURLSuffix の属性のみで 8443 ポートを使って HTTPS URL を設定します。
- HTTPS URL のプロトコルハンドラーは Java で利用できるようにする必要があります。JSSE リリースには、
com.sun.net.ssl.internal.www.protocolパッケージのHTTPS ハンドラーがあります。HTTPS URLを利用可能にするには、標準のURLプロトコルハンドラーの検索プロパティjava.protocol.handler.pkgsにこのパッケージを含める必要があります。Ant スクリプトにjava.protocol.handler.pkgsプロパティを設定します。 - SSLを機能させるには、JSSE セキュリティプロバイダーをインストールする必要があります。これは、JSSE jarsを拡張パッケージとしてインストールするか、プログラムでインストールしてください。この例では煩わしい作業が少ないプログラムでの手法を使っています。
ExClientコードの18行目で、実施方法が説明されています。 - JNDI プロバイダー URL は HTTPS をプロトコルとして利用する必要があります。
ExClientコードの24-25 行目で、ポート番号8443 が割り当てられたローカルホストへのHTTP/SSL 接続を指定しています。このホスト名とポートは、Web コンテナーの SSL コネクターで定義されています。 - サーバー証明に対する HTTPS URLのホストネームの検証は無効にする必要があります。デフォルトでは、JSSE HTTPS プロトコルハンドラーが、HTTPS URL のホスト名部分をサーバー証明の共通名をもとに厳密に検証を行います。これは、セキュリティがかかっている Web サイトに接続すると Web ブラウザーが行うチェックと同じです。特定のホスト名ではなく"
Chapter 8 SSL Example" の共通名を使用する自己署名サーバー証明を採用しており、これは開発環境やイントラネットで一般的に利用されている場合が多いです。JBossHttpInvokerProxyは、org.jboss.security.ignoreHttpsHostシステムプロパティが存在するか、さらにTrue の値を持っているかを確認するデフォルトのホスト名をオーバーライドします。Ant スクリプトではorg.jboss.security.ignoreHttpsHostプロパティを True に設定します。
例8.2 トランスポートとしてHTTPS を使う JNDI クライント
chap3 設定ファイルセットを作成します。
ant -Dchap=naming config
[examples]$ ant -Dchap=naming config
naming 設定ファイルセットを使って JBoss サーバーを起動します。
sh run.sh -c naming
[bin]$ sh run.sh -c naming
ExClient を実行します。
8.4.3. HTTP 経由の JNDI アクセスでセキュリティを確保 リンクのコピーリンクがクリップボードにコピーされました!
InitialContext ファクトリやネーミング操作へ簡単にかつセキュアにアクセスできる点が挙げられます。サーバー側で JNDI/HTTP トランスポートの処理が2つのサーブレットで実装されているため、これが可能となっています。前述したように、これらのサーブレットは、default とall サーバープロファイルの deploy ディレクトリにある http-invoker.sar/invoker.war ディレクトリに含まれています。invoker.war/WEB-INF/web.xml の記述子を編集し、セキュリティ保護がされていないサーブレットマッピングを削除することで、JNDI へのセキュアなアクセスが可能になります。例えば、例8.3「JNDI サーブレットへのアクセスをセキュアにするための web.xml 記述子の例」 のweb.xml 記述子では、ユーザ認証がされており、HttpInvokerのロールを持つ場合のみ、invoker.war サーブレットへのアクセスが可能です。
例8.3 JNDI サーブレットへのアクセスをセキュアにするための web.xml 記述子の例
web.xml 記述子が定義するのは、どのサーブレットがセキュアか、どのロールであればセキュリティ保護されているサーブレットにアクセス可能かのみです。これに加え、war 認証、権限付与を処理するセキュリティドメインを定義する必要があります。定義方法はjboss-web.xml 記述子で行い、http-invokerセキュリティドメインの使用例を以下に示しています。
<jboss-web>
<security-domain>java:/jaas/http-invoker</security-domain>
</jboss-web>
<jboss-web>
<security-domain>java:/jaas/http-invoker</security-domain>
</jboss-web>
security-domain 要素は、認証、権限付与に使う JAAS ログインモジュール設定用のセキュリティドメイン名を定義しています。
8.4.4. セキュリティ保護されていないコンテキストを読み取り専用にして JNDI へのセキュアなアクセスを確保 リンクのコピーリンクがクリップボードにコピーされました!
SRPLoginModule は認証に利用する SRP サーバーインターフェースを検索する必要があります。本項ではここから、JBoss Enterprise Application Platform においてどのように読み取り専用がどのように動作するかを説明していきます。
invoker.sar/WEB-INF/web.xmlでReadOnlyJNDIFactory を宣言すると、/invoker/ReadOnlyJNDIFactoryにマッピングします。
jboss:service=invoker,type=http,target=Naming,readonly=true となっており、http-invoker.sar/META-INF/jboss-service.xml ファイルにて宣言されます。
/invoker/readonly/JMXInvokerServletへの実際の呼出しが含まれています。実際には、これは読み取り専用フィルタが付けられた標準の JMXInvokerServlet となっています。
readOnlyContext パラメーターがreadonlyに設定されていると、ReadOnlyJNDIFactoryからJBoss にアクセスする場合、readonly コンテキストのデータにのみアクセスができるようになっています。使用方法を示すコードを以下に示します。
readonly コンテキストのデータは含まれていませんので、ご自身で作成しない限りreadonly コンテキストの使い道はありません。
8.5. その他のネーミング MBean リンクのコピーリンクがクリップボードにコピーされました!
NamingService MBean 以外に、JBoss に同梱されているネーミング関連のMBean サービスがいくつか存在します。JndiBindingServiceMgr、NamingAlias、ExternalContext、JNDIViewなどとなっています。
8.5.1. JNDI バインディングマネージャー リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.naming.JNDIBindingServiceMgrとなっており、BindingsConfig属性を1つ含んでいます。この属性は、jndi-binding-service_1_0.xsd スキーマをに基づいた XMLドキュメントを受付けます。BindingsConfig 属性のコンテンツは JbossXB フレームワークを使いアンマーシャルされます。以下は MBean の定義で、JNDI バインディングマネージャーサービスの最も基本的なフォーム利用について示しています。
bindexample/message でテキスト文字列 "Hello, JNDI!" をバインドします。アプリケーションは、他のJNDI 値の場合と同様にこの値を検索します。trim 属性は、前後のホワイトスペースを無視するよう指定します。この属性は単に説明のためだけに利用しているため、デフォルト値は True となっています。
InitialContext ctx = new InitialContext();
String text = (String) ctx.lookup("bindexample/message");
InitialContext ctx = new InitialContext();
String text = (String) ctx.lookup("bindexample/message");
type 属性を使って希望のクラス名を指定することができます。
<jndi:binding name="urls/jboss-home">
<jndi:value type="java.net.URL">http://www.jboss.org</jndi:value>
</jndi:binding>
<jndi:binding name="urls/jboss-home">
<jndi:value type="java.net.URL">http://www.jboss.org</jndi:value>
</jndi:binding>
editor 属性を使って、使用するプロパティエディターを指定することができます。
java.util.Properties オブジェクトのマッピング方法を説明しています。
8.5.2. org.jboss.naming.NamingAlias MBean リンクのコピーリンクがクリップボードにコピーされました!
NamingAlias MBean は、単純なユーティリティサービスで、別のJNDI 名で JNDI javax.naming.LinkRef の形式でエイリアスを作成することができます。これは Unix ファイルシステムのシンボリックリンクに似ています。エイリアスを作成するには、NamingAlias MBeanの設定を jboss-service.xml 設定ファイルに追加します。NamingAlias サービスの設定属性は以下の通りです:
- FromName: JNDI 下で
LinkRefがバインドされる場所 - ToName: エイリアスの to name。これは、
LinkRefが参照するターゲット名となっており、この名前はURL、InitialContextを起点とし解決される相対名、あるいはこの名前の最初の文字がドット (.)の場合リンクがバインドされているコンテキストを起点とした相対名となっています。
QueueConnectionFactory をConnectionFactory という名前にマッピングしています。
8.5.3. org.jboss.naming.ExternalContext MBean リンクのコピーリンクがクリップボードにコピーされました!
ExternalContext MBean は、外部の JNDI コンテキストを JBoss サーバーのJNDI 名前空間に連携することができます。外部とは、JBoss サーバー VM の内部で動作する JBossNS ネーミングサービスの外部にあるネーミングサービスを指しています。JNDI プロバイダの root コンテキストがシリアル化されていない場合でも、LDAP サーバー、ファイルシステム、DNS サーバーなどを組み込むことができます。ネーミングサービスがリモートアクセスに対応している場合、リモートクライアントに対してもこの連携を用意することができます。
ExternalContext MBean サービスの設定をjboss-service.xml 設定ファイルに追加する必要があります。ExternalContext サービスの設定可能な属性は以下の通りです。
- JndiName: 外部コンテキストがバインドされる JNDI 名。
- RemoteAccess: リモートクライアントが外部の
InitialContextを作成できるように、Serializableフォームを使って外部のInitialContextをバインドする必要があるかを示すboolean フラグ。リモートクライアントが JBoss JNDIInitialContextを介して外部のコンテキストを検索する場合、ExternalContextMBeanに渡したものと同じ env プロパティを使い、外部のInitialContextのインスタンスを効果的に作成します。クライアントがnew InitialContext(env)をリモートから実行できる場合のみ、機能します。これには、コンテキストにアクセスしているリモート VM にて、env のContext.PROVIDER_URL値が解決できなければなりません。これは、LDAP の例で機能するはずです。しかし、ファイルシステムの例では、ファイルシステムのパスが共通のネットワークパスを指定していない限り機能しない場合が多いでしょう。このプロパティが設定されていないと、デフォルトでFalse に設定されます。 - CacheContext:
cacheContextフラグ。True に設定されている場合、MBean の起動後 MBean が停止するまで in memory オブジェクトとして格納されているときにのみ、外部のContextが作成されます。cacheContext が false に設定されている場合、MBean プロパティとInitialContext クラスを使って検索する度に外部のContextが作成されます。クライアントがキャッシュされていないContextを検索する場合、このクライアントは Context 上でclose()を呼び出し、リソース漏れを防ぐはずです。 - InitialContext: 使用する
InitialContext実装の完全修飾クラス名。以下のいずれかである必要があります:javax.naming.InitialContext,javax.naming.directory.InitialDirContextあるいはjavax.naming.ldap.InitialLdapContext。InitialLdapContextの場合、nullControlsアレイを使用します。デフォルトは、javax.naming.InitialContexとなっています。 - Properties:
Properties属性には 外部のInitialContextに対する JNDI プロパティが含まれます。ここでの入力値はjndi.propertiesファイルに入るテキストと同等のものでなければなりません。 - PropertiesURL: 外部のプロパティファイルから外部の
InitialContextに対するjndi.properties情報を設定します。これは、URL、文字列あるいはクラスパスのリソース名となっており、以下に例を示します。- file:///config/myldap.properties
- http://config.mycompany.com/myldap.properties
- /conf/myldap.properties
- myldap.properties
external/ldap/jboss名の配下で、外部の LDAP コンテキストをJBoss JNDI名前空間にバインドしています。
ldap://ldaphost.jboss.org:389/o=jboss.org にある外部のLDAP にアクセスすることができます。
InitialContext iniCtx = new InitialContext();
LdapContext ldapCtx = iniCtx.lookup("external/ldap/jboss");
InitialContext iniCtx = new InitialContext();
LdapContext ldapCtx = iniCtx.lookup("external/ldap/jboss");
RemoteAccess プロパティが true に設定されたため、JBoss サーバー VMの外部にある同じコードを利用すると動作します。False に設定されている場合、リモートクライアントは、外部の InitialContext を再構築できない ObjectFactory と共にReference オブジェクトを受け取るため、動作しません。
/usr/local をexternal/fs/usr/local名配下にあるJBoss JNDI名前空間へバインディングしています。
file:///usr/local にある外部のファイルシステムコンテキストへアクセス可能です。
InitialContext iniCtx = new InitialContext();
Context ldapCtx = iniCtx.lookup("external/fs/usr/local");
InitialContext iniCtx = new InitialContext();
Context ldapCtx = iniCtx.lookup("external/fs/usr/local");
8.5.4. org.jboss.naming.JNDIView MBean リンクのコピーリンクがクリップボードにコピーされました!
http://localhost:8080/jmx-console/となっています。このページでは、登録済みの MBean をドメイン別に分類し一覧になっているセクションが表示されます。図8.4「設定済みの JBoss MBeans を JMX Console で表示」で示すような表示になるはずです。
図8.4 設定済みの JBoss MBeans を JMX Console で表示
図8.5 JNDIView MBean を JMX Console で表示
図8.6 JNDIView のリスト操作出力をJMX Console で表示
8.6. J2EE および JNDI - アプリケーションコンポーネント環境 リンクのコピーリンクがクリップボードにコピーされました!
- アプリケーションコンポーネントのビジネスロジックは、コード化しENC からの情報にアクセスする必要があります。コンポーネントプロバイダーは、コンポーネントに対して標準の配備記述子を使い、必要とされる ENC エントリを指定します。このエントリは、実行時にコンポーネントが必要とする情報とリソースの宣言をしています。
- このコンテナーが提供するツールでは、コンポーネントのデプロイヤーを使うことで、コンポーネント開発者が作成したENC 参照をこの参照を満たすデプロイメント環境エンティティへマッピングできます。
- コンポーネントデプロイヤーは、コンテナツールを使い最終的なデプロイメントができるようコンポーネントを準備します。
- コンポーネントコンテナーは、デプロイメントパッケージ情報を使ってランタイム時に完全なコンポーネントENC を構築します。
javax.naming.InitialContext オブジェクトを作成してからjava:comp/env名配下にあるネーミング環境を検索します。アプリケーションコンポーネントの環境エントリは ENC に直接格納されるか、あるいはサブコンテキスト内に格納されます。 例8.4「ENCアクセスのサンプルコード」 でコンポーネントがENC にアクセスする際に使うコードの典型的な行を示しています。
例8.4 ENCアクセスのサンプルコード
// Obtain the application component's ENC
Context iniCtx = new InitialContext();
Context compEnv = (Context) iniCtx.lookup("java:comp/env");
// Obtain the application component's ENC
Context iniCtx = new InitialContext();
Context compEnv = (Context) iniCtx.lookup("java:comp/env");
Bean1 は EJB Bean2 のENC 要素にアクセスできず、逆方向でも同様にアクセスできなくなっています。同様に、Web アプリケーションWeb1 は、WEb アプリケーションWeb2、Bean1、あるいはBean2 のENC 要素にアクセスできません。また、任意のクライアントコードはアプリケーションサーバー VM 内外を問わず実行されている場合、コンポーネントのjava:comp JNDI コンテキストにアクセスできません。ENC の目的は、コンポーネントのデプロイ環境タイプに関係なくアプリケーションコンポーネントが依存できる分離型の読み取り専用名前空間を提供することです。各コンポーネントが独自のENC コンテンツを定義するため、ENC は他のコンポーネントから分離する必要があります。たとえば、コンポーネントA と Bが同名定義していても別のオブジェクトを参照している可能性があります。また、別の例を挙げますと、EJB Bean1 は環境エントリjava:comp/env/red を定義し、RGB 色の赤に対して 16 進数を参照している場合があり、一方で Web アプリケーションWeb1 は、同名をデプロイメント環境言語ロケールの赤表示にバインドしている可能性もあります。
java:comp配下の名前、java:配下の名前、その他の名前です。前述したように、java:comp コンテキストとそのサブコンテキストは、特定のコンテキストに紐付けられたアプリケーションコンポーネントに対してのみ利用可能になっています。java:直下のサブコンテキストやオブジェクトバインディングは、JBoss サーバーの下層マシン内でのみ表示され、リモートクライアントからは見えません。コンテキストあるいはオブジェクトがシリアル化に対応していれば、その他のコンテキストやオブジェクトバインディングはリモートクライアントに提供されます。これらのネーミングスコープの分離の実施方法については 「JBoss Naming Service アーキテクチャー」を参照してください。
java: コンテキストへのバインディングを制限すると便利な例は、関連データベースプールが常駐するJBoss サーバー内でのみ利用可能なjavax.sql.DataSourceの接続ファクトリでしょう。一方で、EJB ホームインターフェースは、リモートクライアントからアクセスできるはずのグローバルな表示名にバインドされるでしょう。
8.6.1. ENC の使用規則 リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml 配備記述子および Web コンポーネント用の標準 web.xml 配備記述子内に宣言されます。次のような様々な種類の情報が JNDI 内に格納、検索されます。
env-entry要素により宣言された通りの環境エントリejb-refとejb-local-ref要素により宣言された通りのEJB 参照resource-ref要素が宣言した通りのリソースマネージャー接続ファクトリ参照resource-env-ref要素に定義された通りのリソース環境参照
8.6.1.1. 環境エントリ リンクのコピーリンクがクリップボードにコピーされました!
env-entry を使い宣言されます。env-entry要素には以下の子要素が含まれます:
- エントリの詳細を提供する任意のdescription 要素
java:comp/envに相対となるエントリ名を渡すenv-entry-name要素- エントリ値の java タイプを与えるenv-entry-type要素。このエントリ値のタイプは以下のいずれかでなければなりません。
java.lang.Bytejava.lang.Booleanjava.lang.Characterjava.lang.Doublejava.lang.Floatjava.lang.Integerjava.lang.Longjava.lang.Shortjava.lang.String
- 文字列としてエントリ値を与えるenv-entry-value 要素
ejb-jar.xml 配備記述子からのenv-entry フラグメントに関する例が例8.5「ejb-jar.xml env-entry のフラグメント例」に提供されています。env-entryは完全名かつ値の指定であるため、JBoss 固有の配備記述子要素はありません。例8.6「ENC env-entry アクセスコード」では、配備記述子で宣言されているmaxExemptions 値、taxRate 値、env-entry 値へアクセスするための、サンプルコードを提示しています。
例8.5 ejb-jar.xml env-entry のフラグメント例
例8.6 ENC env-entry アクセスコード
InitialContext iniCtx = new InitialContext();
Context envCtx = (Context) iniCtx.lookup("java:comp/env");
Integer maxExemptions = (Integer) envCtx.lookup("maxExemptions");
Float taxRate = (Float) envCtx.lookup("taxRate");
InitialContext iniCtx = new InitialContext();
Context envCtx = (Context) iniCtx.lookup("java:comp/env");
Integer maxExemptions = (Integer) envCtx.lookup("maxExemptions");
Float taxRate = (Float) envCtx.lookup("taxRate");
8.6.1.2. EJB参照 リンクのコピーリンクがクリップボードにコピーされました!
java:comp/env/ejb コンテキスト内にまとめるよう推奨しています。
ejb-ref 要素を使い配備記述子で宣言します。各 ejb-ref 要素は、参照アプリケーションコンポーネントが参照されるエンタープライズ bean に対して持つインターフェース要件を記述します。ejb-ref 要素には以下の子要素が含まれます。
- 参照の目的を示すオプションのdescription 要素。
- ejb-ref-name 要素で、
java:comp/envコンテキストに対して相対となる参照名を指定します。推奨のjava:comp/env/ejbコンテキスト配下に参照を置くには、ejb-ref-name値に対して、ejb/link-name形式を使います。 - EJB の種類を指定するejb-ref-type 要素。
EntityあるいはSessionでなければなりません。 - EJB ホームインターフェースの完全修飾クラス名を提供するhome 要素。
- EJB リモートインターフェースの完全修飾クラス名を提供するremote 要素。
- オプションの ejb-link 要素で同じ EJB JAR または同じ J2EE アプリケーションユニットにある別のエンタープライズ bean に参照をリンクします。
ejb-link値は参照される bean のejb-nameになります。同じejb-nameを持つエンタープライズ bean が複数ある場合、値はパス名前を使用して、参照コンポーネントを含むejb-jarファイルの場所を指定します。パス名は参照ejb-jarファイルに相対的となります。Application Assembler は参照される bean のejb-nameを#で区切ってパス名に追加します。これにより同じ名前を持つ複数の bean が一意に識別可能となります。
ejb-ref 要素を含むアプリケーションコンポーネントにスコープ設定されます。つまり、EJB 参照は実行時には他のアプリケーションコンポーネントからアクセスできず、他のアプリケーションコンポーネントは名前の衝突を起こさずejb-ref要素を同じejb-ref-name で定義できます。例8.7「ejb-jar.xml 内 ejb-ref 記述子の部分例」 では、ejb-refの使用方法を説明するejb-jar.xml フラグメントを提示しています。例8.7「ejb-jar.xml 内 ejb-ref 記述子の部分例」 にて宣言されているShoppingCartHome 参照にアクセスするためのコード例は、例8.8「ENC ejb-ref アクセスコード」に提供されています。
例8.7 ejb-jar.xml 内 ejb-ref 記述子の部分例
例8.8 ENC ejb-ref アクセスコード
InitialContext iniCtx = new InitialContext();
Context ejbCtx = (Context) iniCtx.lookup("java:comp/env/ejb");
ShoppingCartHome home = (ShoppingCartHome) ejbCtx.lookup("ShoppingCartHome");
InitialContext iniCtx = new InitialContext();
Context ejbCtx = (Context) iniCtx.lookup("java:comp/env/ejb");
ShoppingCartHome home = (ShoppingCartHome) ejbCtx.lookup("ShoppingCartHome");
8.6.1.3. jboss.xml および jboss-web.xml でのEJB 参照 リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml EJB 配備記述子はEJB 参照に2通りに作用します。まず、session の jndi-name の子要素とentity 要素により、ユーザがEJB ホームインターフェースに対してデプロイメントJNDI 名を指定することができます。EJB に対し jndi-name をjboss.xml で指定しない場合、ホームインターフェースは、ejb-jar.xmlejb-name 値の配下にバインドされます。例えば、例8.7「ejb-jar.xml 内 ejb-ref 記述子の部分例」 にあるShoppingCartBean のejb-nameを持つセッションEJB では、jboss.xmljndi-name の指定がないため、ホームインターフェースはJNDI 名の配下にバインドされます。
ejb-ref関連のjboss.xml 記述子に関する2つ目の用途は、コンポーネントのENC ejb-ref の参照先を設定します。ejb-link 要素を使って別の企業アプリケーションにあるEJBを参照することはできません。ご利用中のejb-ref が外部のEJBにアクセスする必要がある場合、jboss.xmlejb-ref/jndi-name 要素を使って、配備されたEJB ホームのJNDI 名を指定することができます。
jboss-web.xml 記述子は、Web アプリケーションのENCejb-ref の参照先を設定するためだけに利用されます。JBoss ejb-refのコンテンツモデルは以下の通りです。
- ejb-jar.xml あるいはweb.xml標準記述子内のejb-ref-name 要素に相当する ejb-ref-name 要素。
- デプロイメント環境でEJB ホームインターフェースのJNDI 名を指定する
jndi-name要素。
jboss.xml 記述子の部分例となっています。
ProductBeanUserejb-refのリンク先は、jboss/store/ProductHomeのデプロイメント名に設定されます。ProductBeanのデプロイメントJNDI 名は、jboss/store/ProductHomeと設定されます。
例8.9 jboss.xml ejb-ref の部分例
8.6.1.4. EJB のローカル参照 リンクのコピーリンクがクリップボードにコピーされました!
java:comp/env/ejbコンテキスト内に、エンタープライズ bean への参照をすべて整理するよう推奨しています。
ejb-local-ref 要素を使って宣言されます。各 ejb-local-ref 要素は、参照されるエンタープライズ bean に対する、参照アプリケーションのインターフェース要件を記述しています。ejb-local-ref 要素には以下の子要素が含まれます。
- 参照の目的を示すオプションのdescription 要素。
- ejb-ref-name 要素で、
java:comp/envコンテキストに対して相対となる参照名を指定します。推奨のjava:comp/env/ejbコンテキスト配下に参照を置くには、ejb-ref-name値に対して、ejb/link-name形式を使います。 - EJB の種類を指定するejb-ref-type 要素。
EntityあるいはSessionでなければなりません。 - EJB ローカルホームインターフェースの完全修飾クラス名を提供するlocal-home。
- EJB ローカルインターフェースの完全修飾クラス名を提供するlocal 要素。
ejb-jarファイルまたは、同じJ2EE アプリケーションユニット内にある別のエンタープライズ bean への参照にリンクするejb-link要素。ejb-link値は、参照されたbean のejb-nameとなっています。同じejb-nameを持つエンタープライズ bean が複数存在する場合、この値はパス名を使い、参照コンポーネントを含むejb-jarファイルの場所を指定します。Application Assembler は、#で区切られたパス名に参照 bean のejb-nameを付けます。これにより、同名を持つ bean が複数あっても一意に識別できるようになります。JBoss ではejb-link要素を指定し、ローカル参照と対応するEJBを一致させる必要があります。
ejb-local-ref 要素を含むアプリケーションコンポーネントにスコープ化されます。つまり、EJB ローカル参照は、ランタイム時に他のアプリケーションコンポーネントからアクセスできず、別のアプリケーションコンポーネントは名前の衝突なしに同じejb-ref-name を持つejb-local-ref 要素を定義する場合があるのです。例8.10「ejb-jar.xml ejb-local-ref 記述子の部分例」では、ejb-local-ref の用途について例示するejb-jar.xml のフラグメントが提供されています。例8.11「ENC ejb-local-ref アクセスコード」 のコード例にて、例8.10「ejb-jar.xml ejb-local-ref 記述子の部分例」で宣言されるProbeLocalHome 参照へのアクセスについて例示しています。
例8.10 ejb-jar.xml ejb-local-ref 記述子の部分例
例8.11 ENC ejb-local-ref アクセスコード
InitialContext iniCtx = new InitialContext();
Context ejbCtx = (Context) iniCtx.lookup("java:comp/env/ejb");
ProbeLocalHome home = (ProbeLocalHome) ejbCtx.lookup("ProbeLocalHome");
InitialContext iniCtx = new InitialContext();
Context ejbCtx = (Context) iniCtx.lookup("java:comp/env/ejb");
ProbeLocalHome home = (ProbeLocalHome) ejbCtx.lookup("ProbeLocalHome");
8.6.1.5. リソースマネージャー接続ファクトリの参照 リンクのコピーリンクがクリップボードにコピーされました!
resource-ref 要素により定義されています。Deployer は、jboss.xml と jboss-web.xml 記述子を使って、リソースマネージャー接続ファクトリの参照を実際の運用環境にあるリソースマネージャー接続ファクトリにバインドします。
resource-ref 要素は、1つのリソースマネージャー接続ファクトリの参照を記述します。resource-ref 要素は、以下の子要素で構成されます:
- 参照の目的を示すオプションのdescription 要素。
java:comp/envコンテキストを起点とした参照名を指定するres-ref-name 要素。どのサブコンテキストにres-ref-nameを配置するかを決定するリソースタイプに基づいた命名規則について、次の段落にて説明します。- リソースマネージャー接続ファクトリの完全修飾名を指定するres-type 要素。
- アプリケーションコンポーネントコードがリソースのサインオンをプログラムで実行するか、あるいはコンテナーがデプロイヤー提供の主体マッピング情報に基づいたリソースへサインオンするか示すres-auth 要素。
ApplicationあるいはContainerのいずれかでなければなりません。 - 任意のres-sharing-scope 要素。現在、JBoss では対応していません。
- JDBC
DataSource参照は、java:comp/env/jdbcのサブコンテキストで宣言する必要があります。 - JMS 接続ファクトリは
java:comp/env/jmsサブコンテキストで宣言する必要があります。 - JavaMail 接続ファクトリは
java:comp/env/mailサブコンテキストにて宣言する必要があります。 - URL 接続ファクトリは、
java:comp/env/urlサブコンテキストにて宣言する必要があります。
resource-ref 要素の用途を示すweb.xml 記述子のフラグメント例です。例8.13「ENC resource-ref アクセスのサンプルコード」 は、アプリケーションコンポーネントが resource-refにより宣言されている DefaultMail リソースへアクセスする際に使うコードを提供しています。
例8.12 web.xml resource-ref 記述子のフラグメント
例8.13 ENC resource-ref アクセスのサンプルコード
Context initCtx = new InitialContext();
javax.mail.Session s = (javax.mail.Session)
initCtx.lookup("java:comp/env/mail/DefaultMail");
Context initCtx = new InitialContext();
javax.mail.Session s = (javax.mail.Session)
initCtx.lookup("java:comp/env/mail/DefaultMail");
8.6.1.6. jboss.xml と jboss-web.xml でのリソースマネージャー接続ファクトリの接続 リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml EJB 配備記述子とjboss-web.xml Web アプリケーションの配備記述子の目的は、jboss-web.xml 要素により定義された論理名からJBoss でデプロイされるリソースファクトリのJNDI 名へのリンクを提供することです。jboss.xml あるいはjboss-web.xml 記述子にresource-ref 要素を提供することでリンク可能です。JBoss resource-ref 要素には、以下の子要素が含まれています:
- res-ref-name要素。これは、
ejb-jar.xmlあるいはweb.xmlの標準記述子にある該当のresource-ref要素のres-ref-nameと一致しなければなりません。 - 任意のres-type 要素。リソースマネージャー接続ファクトリの完全修飾クラス名を指定します。
- jndi-name要素。これは、JBoss にデプロイされるように、リソースファクトリのJNDI 名を指定します。
- res-url要素。これは、
resource-refがタイプjava.net.URLの場合にURL文字列を指定します。
jboss-web.xml のサンプル記述子を提示しています。このフラグメントでは例8.12「web.xml resource-ref 記述子のフラグメント」にあるresource-ref要素のサンプルマッピングが示されています。
例8.14 jboss-web.xml resource-ref 記述子の例
8.6.1.7. リソース環境の参照 リンクのコピーリンクがクリップボードにコピーされました!
resource-env-ref 要素で定義されています。Deployerは、jboss.xml と jboss-web.xml記述子を使うことで、リソース環境の参照を対象の運用環境にある実際の管理オブジェクトの場所にバインドします。
resource-env-ref 要素はそれぞれ、参照される管理オブジェクトに対し参照するアプリケーションコンポーネントが必要とする要件を記述します。resource-env-ref 要素には、以下の子要素が含まれます:
- 参照の目的を示すオプションのdescription 要素。
java:comp/envコンテキストを起点とした参照名を指定するresource-env-ref-name 要素。規則は関連のリソースファクトリタイプに対応するサブコンテキスト内にその名前を配置します。たとえば、MyQueueという名前の JMS キュー参照はjms/MyQueueのresource-env-ref-nameを持っているはずです。- 参照されるオブジェクトの完全修飾クラス名を指定するresource-env-ref-type 要素。例えば、JMS キューの場合、値は
javax.jms.Queueとなります。
resource-ref-env要素の宣言例を示しています。例8.16「ENC resource-env-ref アクセスコード」 では、resource-env-refにより宣言されたStockInfo キューを検索する方法を示すコードを提供しています。
例8.15 ejb-jar.xml resource-env-ref のフラグメント例
例8.16 ENC resource-env-ref アクセスコード
InitialContext iniCtx = new InitialContext();
javax.jms.Queue q = (javax.jms.Queue)
envCtx.lookup("java:comp/env/jms/StockInfo");
InitialContext iniCtx = new InitialContext();
javax.jms.Queue q = (javax.jms.Queue)
envCtx.lookup("java:comp/env/jms/StockInfo");
8.6.1.8. リソース環境参照と jboss.xml、jboss-web.xml リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml EJB 配備記述子とjboss-web.xml Web アプリケーションの配備記述子の目的は、resource-env-ref-name 要素により定義された論理名からJBoss でデプロイされる管理オブジェクトのJNDI 名へのリンクを提供することです。jboss.xml あるいはjboss-web.xml 記述子にresource-env-ref 要素を提供することでリンク可能です。JBoss jboss-web.xml 要素には、以下の子要素が含まれています:
resource-env-ref-name要素。ejb-jar.xmlあるいはweb.xmlの標準記述子からの該当のresource-env-ref要素にあるresource-env-ref-nameと一致しなければなりません。- JBoss でデプロイされるようにリソースのJNDI 名を指定する
jndi-name要素。
StockInforesource-env-refに関するマッピングサンプルを示すjboss.xml 記述子の例を提供しています。
例8.17 jboss.xml resource-env-ref 記述子のフラグメント例
第9章 Web サービス リンクのコピーリンクがクリップボードにコピーされました!
警告
9.1. Web サービスの必要性 リンクのコピーリンクがクリップボードにコピーされました!
9.2. Web サーバーとは リンクのコピーリンクがクリップボードにコピーされました!
9.3. Document/Literal リンクのコピーリンクがクリップボードにコピーされました!
<message name='EndpointInterface_concat'> <part name='parameters' element='tns:concat'/> </message>
<message name='EndpointInterface_concat'>
<part name='parameters' element='tns:concat'/>
</message>
<message name='EndpointInterface_concat'> <part name='parameters' type='tns:concatType'/> </message>
<message name='EndpointInterface_concat'>
<part name='parameters' type='tns:concatType'/>
</message>
9.4. Document/Literal (Bare) リンクのコピーリンクがクリップボードにコピーされました!
9.5. Document/Literal (Wrapped) リンクのコピーリンクがクリップボードにコピーされました!
注記
9.6. RPC/Literal リンクのコピーリンクがクリップボードにコピーされました!
- ポートタイプ操作名がエンドポイントメソッド名を定義する。
- メッセージ部分はエンドポイントメソッドパラメーターである。
注記
9.7. RPC/Encoded リンクのコピーリンクがクリップボードにコピーされました!
- 要素の参照
- bean プロパティとしての soap 配列
注記
9.8. Web サービスのエンドポイント リンクのコピーリンクがクリップボードにコピーされました!
9.9. POJO (Plain old Java Object) リンクのコピーリンクがクリップボードにコピーされました!
9.10. Web アプリケーションとしてのエンドポイント リンクのコピーリンクがクリップボードにコピーされました!
9.11. エンドポイントのパッケージ化 リンクのコピーリンクがクリップボードにコピーされました!
*.war ファイルにパッケージ化されます。
<war warfile="${build.dir}/libs/jbossws-samples-jsr181pojo.war" webxml="${build.resources.dir}/samples/jsr181pojo/WEB-INF/web.xml">
<classes dir="${build.dir}/classes">
<include name="org/jboss/test/ws/samples/jsr181pojo/JSEBean01.class"/>
</classes>
</war>
<war warfile="${build.dir}/libs/jbossws-samples-jsr181pojo.war" webxml="${build.resources.dir}/samples/jsr181pojo/WEB-INF/web.xml">
<classes dir="${build.dir}/classes">
<include name="org/jboss/test/ws/samples/jsr181pojo/JSEBean01.class"/>
</classes>
</war>
注記
web.xml ファイルのみが必要となります。
9.12. 生成された WSDL にアクセス リンクのコピーリンクがクリップボードにコピーされました!
http://yourhost:8080/jbossws/services
http://yourhost:8080/jbossws/services
9.13. EJB3 ステートレスセッション Bean (SLSB) リンクのコピーリンクがクリップボードにコピーされました!
JSR-181 EJB サービスのエンドポイントは通常の ejb デプロイメントとしてパッケージ化されます。
正しくデプロイされたサービスエンドポイントはサービスエンドポイントマネージャーに表示されます。 サービスエンドポイントマネージャーには生成された WSDL へのリンクもあります。
http://yourhost:8080/jbossws/services
http://yourhost:8080/jbossws/services
9.14. エンドポイントプロバイダー リンクのコピーリンクがクリップボードにコピーされました!
9.15. WebServiceContext リンクのコピーリンクがクリップボードにコピーされました!
WebServiceContext はエンドポイントが初期化される時点で設定できるインジェクションが可能リソースとして扱われます。 WebServiceContext オブジェクトは次に、 同じエンドポイントオブジェクト宛ての複数の要求処理に同時使用されているスレッド数に関係なく、 スレッドローカル情報を使用して正しい情報を返します。
9.16. Web サービスのクライアント リンクのコピーリンクがクリップボードにコピーされました!
9.16.1. サービス リンクのコピーリンクがクリップボードにコピーされました!
Service は WSDL サービスを表す抽象になります。 WSDL サービスは関連ポートの集合で、 それぞれが特定のプロトコルにバインドするポートタイプから構成されます。 また、特定のエンドポイントアドレスで使用可能になります。
9.16.1.1. サービスの使用 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどのクライアントは WSDL ファイルで開始し、 wsconsume のような jbossws ツールを使っていくつかのスタブを生成します。 これは通常、 膨大なファイル数となり、 そのうちのひとつがツリーのトップになります。 これがサービス実装クラスです。
動的な場合、 何も生成されないと Web サービスクライアントは Service.create を使って Service インスタンスを作成します。 次のコードでこのプロセスを示します。
URL wsdlLocation = new URL("http://example.org/my.wsdl");
QName serviceName = new QName("http://example.org/sample", "MyService");
Service service = Service.create(wsdlLocation, serviceName);
URL wsdlLocation = new URL("http://example.org/my.wsdl");
QName serviceName = new QName("http://example.org/sample", "MyService");
Service service = Service.create(wsdlLocation, serviceName);
9.16.1.2. ハンドラーリゾルバー リンクのコピーリンクがクリップボードにコピーされました!
Service インスタンスは、 サービス毎やポート毎、 プロトコルバインディング毎にハンドラーセットを設定することができる getHandlerResolver メソッドと setHandlerResolver メソッドのペアで HandlerResolver へのアクセスを提供します。
Service インスタンスがプロキシまたは Dispatch インスタンスの作成に使用されると、 現在そのサービスで登録されているハンドラーリゾルバーが要求されるハンドラーチェーンの作成に使用されます。続いて起こる Service インスタンス用に設定されるハンドラーリゾルバーへの変更は前に作成されたプロキシあるいは Dispatch のインスタンスにあるハンドラーには影響しません。
9.16.1.3. Executor リンクのコピーリンクがクリップボードにコピーされました!
Service インスタンスは java.util.concurrent.Executor で設定することができます。 次にエグゼキューターを使ってアプリケーションが要求するすべての非同期のコールバックが呼び出されます。Service の setExecutor と getExecutor のメソッドを使ってサービス用に設定されるエグゼキューターを編集して読み出すことができます。
9.16.2. 動的なプロキシ リンクのコピーリンクがクリップボードにコピーされました!
Service の getPort メソッドの 1 つを使ってクライアントプロキシのインスタンスを作成することができます。
Service は通常、型指定されたメソッドも提供しポートを取得します。これらのメソッドは SEI を実装する動的なプロキシも返します。
9.16.3. WebServiceRef リンクのコピーリンクがクリップボードにコピーされました!
WebServiceRef アノテーションは Web サービスに対する参照の宣言に使用されます。 JSR-250 にある javax.annotation.Resource で範例されるリソースパターンに従います。
WebServiceRef アノテーションには 2 通りの使い方があります。
- タイプが生成されたサービスクラスである参照を定義します。 この場合、 タイプと値要素はいずれも生成されたサービスクラス型を参照します。 さらに、 その参照タイプがアノテーションが適用されるフィールド/メソッド宣言で推測できる場合、 タイプおよび値要素はデフォルトの値 (
Object.class) とすることもできます。 タイプが推測できない場合は、 最低でもタイプ要素がデフォルト以外の値でなければなりません。 - タイプが SEI の参照を定義します。 この場合、 その参照タイプがアノテーションが付けられたフィールド/メソッド宣言から推測できればタイプ要素はデフォルトでも構いませんが、 値要素は常に存在しなければならず、生成されたサービスクラスタイプ (
javax.xml.ws.Serviceのサブタイプ)を参照しなければなりません。 wsdlLocation 要素が存在する場合、 参照され生成されたサービスクラスのWebServiceアノテーションに指定された theWSDL の場所情報よりも優先されます。
JBoss Enterprise Application Platform 5.0 は WebServiceRef アノテーションへのオーバーライドや拡張を多数提供します。以下のようなものが含まれます。
- コンテナ管理ポートを解決するために使用されるべきポートの定義
- Stub オブジェクトに対するデフォルトの Stub プロパティ設定の定義
- 最終的に使用される WSDL ドキュメントの URL 定義
9.16.4. Dispatch リンクのコピーリンクがクリップボードにコピーされました!
このモードでは、 クライアントアプリケーションは直接プロトコル固有のメッセージ構造と動作します。 例、 SOAP プロトコルバインディングと併用する場合、 クライアントアプリケーションは直接 SOAP メッセージと動作します。
このモードでは、 クライアントアプリケーションはメッセージ自体ではなくメッセージのペイロードと動作します。 例、 SOAP プロトコルバインディングと併用する場合、 クライアントアプリケーションは SOAP メッセージ全体ではなく SOAP Body の内容と動作します。
9.16.5. 非同期の呼び出し リンクのコピーリンクがクリップボードにコピーされました!
BindingProvider インターフェースはクライアントによる使用を目的としたプロトコルバインディングを提供するコンポーネントを表し、 プロキシによって実装、 Dispatch インターフェースによって拡張されます。
BindingProvider インスタンスは非同期の動作機能を提供することができます。 使用した場合、 動作が完了するとレスポンスコンテキストは更新されないなど、 呼び出し時に非同期の動作呼び出しが BindingProvider インスタンスから分離されます。 代わりに、 別のレスポンスコンテキストが Response インターフェースを使って利用できるようになります。
9.16.6. Oneway 呼び出し リンクのコピーリンクがクリップボードにコピーされました!
9.17. 共通 API リンクのコピーリンクがクリップボードにコピーされました!
9.17.1. ハンドラーフレームワーク リンクのコピーリンクがクリップボードにコピーされました!
9.17.1.1. 論理ハンドラー リンクのコピーリンクがクリップボードにコピーされました!
javax.xml.ws.handler.LogicalHandler を実装するハンドラーになります。
9.17.1.2. プロトコルハンドラー リンクのコピーリンクがクリップボードにコピーされました!
javax.xml.ws.handler.LogicalHandler 以外の javax.xml.ws.handler.Handler から生じたあらゆるインターフェースを実装するハンドラーになります。
9.17.1.3. サービスエンドポイントのハンドラー リンクのコピーリンクがクリップボードにコピーされました!
9.17.1.4. サービスクライアントのハンドラー リンクのコピーリンクがクリップボードにコピーされました!
9.17.2. メッセージコンテキスト リンクのコピーリンクがクリップボードにコピーされました!
9.17.2.1. メッセージコンテキストへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
@WebService アノテーションよりハンドラーまたはエンドポイントのメッセージコンテクストへアクセスすることができます。
9.17.2.2. 論理メッセージコンテキスト リンクのコピーリンクがクリップボードにコピーされました!
Logical Handlers へ渡されます。 LogicalMessageContext は、 メッセージペイロードを取得し変更するメソッドを用いて MessageContext を拡張し、 メッセージのプロトコル固有アスペクトへのアクセスは提供しません。 プロトコルバインディングは、 論理メッセージコンテキストより使用できるメッセージのコンポーネントを定義します。 SOAP バインディングは、 SOAP バインディングにデプロイされた論理ハンドラは SOAP ボディーの内容にはアクセス可能で、 SOAP ヘッダにはアクセスできないことを定義します。 XML/HTTP バインディングは、 論理ハンドラーがメッセージの XML ペイロード全体にアクセスできることを定義します。
9.17.2.3. SOAP メッセージコンテキスト リンクのコピーリンクがクリップボードにコピーされました!
SOAP handlers へ渡されます。 SOAPMessageContext は、 SOAP メッセージペイロードを取得し変更するメソッドを用いて MessageContext を拡張します。
9.17.3. 障害の処理 リンクのコピーリンクがクリップボードにコピーされました!
public void throwApplicationException() throws UserException
{
throw new UserException("validation", 123, "Some validation error");
}
public void throwApplicationException() throws UserException
{
throw new UserException("validation", 123, "Some validation error");
}
注記
9.18. DataBinding リンクのコピーリンクがクリップボードにコピーされました!
9.18.1. アノテーションが付けられていないクラスで JAXB を使用 リンクのコピーリンクがクリップボードにコピーされました!
9.19. 添付 リンクのコピーリンクがクリップボードにコピーされました!
9.19.1. MTOM/XOP リンクのコピーリンクがクリップボードにコピーされました!
9.19.1.1. 対応 MTOM パラメータータイプ リンクのコピーリンクがクリップボードにコピーされました!
|
image/jpeg
|
java.awt.Image
|
|
text/xml
|
javax.xml.transform.Source
|
|
application/xml
|
javax.xml.transform.Source
|
|
application/octet-stream
|
javax.activation.DataHandler
|
注記
9.19.1.2. エンドポイントごとに MTOM を有効にする方法 リンクのコピーリンクがクリップボードにコピーされました!
@BindingType アノテーションで有効にされます。 JBossWS は SOAP1.1 および SOAP1.2 を処理します。 いずれも MTOM があってもなくても使用できます。
- MTOM 有効の SOAP 1.1 バインディング ID
Binding API に依存することができます (org.jboss.test.ws.jaxws.samples.xop.doclit.XOPTestCase からの抜粋):
注記
9.19.2. SwaRef リンクのコピーリンクがクリップボードにコピーされました!
9.19.2.1. SwaRef と JAX-WS エンドポイントを併用 リンクのコピーリンクがクリップボードにコピーされました!
DataHandler タイプに対して SwaRef エンコーディングを有効にする最もシンプルな方法は、 以下のようにペイロード bean に @XmlAttachmentRef アノテーションを付ける方法です。
@XmlAttachmentRef アノテーションを指定することさえ可能です。
9.19.2.2. WSDL から開始 リンクのコピーリンクがクリップボードにコピーされました!
<element name="data" type="wsi:swaRef" xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd"/>
<element name="data" type="wsi:swaRef"
xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd"/>
9.20. ツール リンクのコピーリンクがクリップボードにコピーされました!
- すでに存在する EJB3 bean を Web Service として公開
- 新しいサービスを提供する、 コントラクトの生成が必要
- 旧式クライアントとの互換性を維持しながら既存 Web サービスの実装を置き換える
- サードパーティによって指定されるコントラクトに適合するサービスを公開する (例:定義済みのプロトコルを使ってコールバックを行うベンダー)
- 前もって手動で開発した WSDL と XML スキーマを厳守するサービスを作成する
|
コマンド
|
内容
|
|
移植性のある JAX-WS アーチファクトを生成し、 抽象規定を提供します。 bottom-up 開発で使用されます。
| |
|
抽象規定 (SWDL と Schema ファイル) を摂取して、 サーバーおよびクライアントの両方にアーチファクトを生成します。 top-down およびクライアント開発に使用されます。
| |
|
JBossWS クラスパスを使って Java クライアント (1 つの main メソッドを持つ) を実行します。
|
9.20.1. Bottom-Up (wsprovide を使用) リンクのコピーリンクがクリップボードにコピーされました!
<service name='EchoService'>
<port binding='tns:EchoBinding' name='EchoPort'>
<soap:address location='REPLACE_WITH_ACTUAL_URL'/>
</port>
</service>
<service name='EchoService'>
<port binding='tns:EchoBinding' name='EchoPort'>
<soap:address location='REPLACE_WITH_ACTUAL_URL'/>
</port>
</service>
注記
web.xml を作成する必要があります。
web.xml および単一クラスを使用して WAR を作成できるようになりました。
cp echo.war <replaceable>$JBOSS_HOME</replaceable>/server/default/deploy
cp echo.war <replaceable>$JBOSS_HOME</replaceable>/server/default/deploy
9.20.2. Top-Down (wsconsume を使用) リンクのコピーリンクがクリップボードにコピーされました!
注記
|
ファイル
|
目的
|
|
Echo.java
|
Service Endpoint Interface
|
|
Echo_Type.java
|
要求メッセージに対するラッパー bean
|
|
EchoResponse.java
|
レスポンスメッセージに対するラッパー bean
|
|
ObjectFactory.java
|
JAXB XML レジストリ
|
|
package-info.java
|
JAXB パッケージアノテーションのホルダー
|
|
EchoService.java
|
JAX-WS クライアントによってのみ使用される
|
9.20.3. クライアント側 リンクのコピーリンクがクリップボードにコピーされました!
<service name='EchoService'>
<port binding='tns:EchoBinding' name='EchoPort'>
<soap:address location='REPLACE_WITH_ACTUAL_URL'/>
</port>
</service>
<service name='EchoService'>
<port binding='tns:EchoBinding' name='EchoPort'>
<soap:address location='REPLACE_WITH_ACTUAL_URL'/>
</port>
</service>
<service name="EchoService">
<port binding="tns:EchoBinding" name="EchoPort">
<soap:address location="http://localhost.localdomain:8080/echo/Echo"/>
</port>
</service>
<service name="EchoService">
<port binding="tns:EchoBinding" name="EchoPort">
<soap:address location="http://localhost.localdomain:8080/echo/Echo"/>
</port>
</service>
EchoService.java は top-down セクションでは確認しなかったクラスでした。 WSDL の取得先となる場所を格納する方法に注目してください。
javax.xml.ws.Service 内のメインクライアントエントリポイントを拡張するクラスを生成しました。 Service を直接使用できる一方、 設定情報を提供してくれるためこちらの方がずっと簡単になります。 本当に注意しなければならないメソッドは getEchoPort() メソッドのみで、 Service Endpoint Interface のインスタンスを返します。 これであらゆる WS オペレーションが返されるインターフェースでメソッドを呼び出すだけで呼び出し可能になります。
注記
wsrunclient EchoClient 'Hello World!' Server said: Hello World!
$ wsrunclient EchoClient 'Hello World!'
Server said: Hello World!
9.20.4. コマンドライン & Ant タスク参照 リンクのコピーリンクがクリップボードにコピーされました!
9.20.5. JAX-WS バインディングのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
9.21. Web サービスの拡張 リンクのコピーリンクがクリップボードにコピーされました!
9.21.1. WS-Addressing リンクのコピーリンクがクリップボードにコピーされました!
9.21.1.1. 仕様 リンクのコピーリンクがクリップボードにコピーされました!
9.21.1.2. エンドポイントの処理 リンクのコピーリンクがクリップボードにコピーされました!
注記
javax.xml.ws.soap.Addressing アノテーションを使用してサーバー側のアドレッシングハンドラーを有効にします。
9.21.1.3. クライアントの処理 リンクのコピーリンクがクリップボードにコピーされました!
javax.xml.ws.soap.AddressingFeature を使用して WS-Addressing を有効にします。
Service service = Service.create(wsdlURL, serviceName); port1 = (StatefulEndpoint)service.getPort(StatefulEndpoint.class, new AddressingFeature());
Service service = Service.create(wsdlURL, serviceName);
port1 = (StatefulEndpoint)service.getPort(StatefulEndpoint.class, new AddressingFeature());
9.21.2. WS-Security リンクのコピーリンクがクリップボードにコピーされました!
9.21.2.1. エンドポイント設定 リンクのコピーリンクがクリップボードにコピーされました!
注記
9.21.2.2. サーバー側 WSSE 宣言 (jboss-wsse-server.xml) リンクのコピーリンクがクリップボードにコピーされました!
- これは、使用したいキーストアは war ファイルにある
WEB-INF/wsse.keystoreであることを指定します。 - ストアパスワードは「jbossws」であることを指定しています。 パスワードは {EXT} と {CLASS} のコマンドを使って暗号化することができます。 使用方法についてはサンプルをご覧ください。
- これは、使用したいキーストアは war ファイルにある
WEB-INF/wsse.truststoreであることを指定します。 - 信頼できるストアパスワードも「jbossws」であることを指定しています。 パスワードは {EXT} と {CLASS} のコマンドを使って暗号化することができます。 使用方法についてはサンプルをご覧ください。
- root config ブロックはここから開始します。 root config ブロックはこの war ファイル内のすべてのサービスに対してデフォルト設定となります。
- サーバーはすべてのレスポンスのメッセージボディに署名しなければならないという意味になります。 Type は X.509v3 証明書 (標準の証明書) を使用しているという意味です。 エイリアスオプションは、 署名に使用する証明書とキーの組み合わせは「wsse」エイリアス配下のキーストアにあることを示しています。
- オプションの requires ブロックはここから開始します。 このブロックはサーバーがメッセージを受信するときに満たされる必要のある全セキュリティ要件を指定します。
- この war ファイル内の Web サービスはすべて署名すべきメッセージボディを必要とします。
@EndpointConfig アノテーションを使って設定名を指定します。 使用できる設定名の一覧は JAX-WS_Endpoint_Configuration をご覧ください。
9.21.2.3. クライアント側 WSSE 宣言 (jboss-wsse-client.xml) リンクのコピーリンクがクリップボードにコピーされました!
- root config ブロックはここから開始します。 root config ブロックはすべての Web サービスクライアントに対してデフォルトの設定となります (Call、 Proxy オブジェクト)。
- クライアントは送信するすべての要求のメッセージボディに署名しなければならないという意味になります。 Type は X.509v3 証明書 (標準の証明書) を使用しようとしていることを意味します。 エイリアスオプションは署名に使用する証明書とキーの組み合わせが「wsse」エイリアス配下のキーストアにあることを示しています。
- オプションの requires ブロックはここから開始します。 このブロックはクライアントがレスポンスを受信するときに満たされなければならない全セキュリティ要件を指定します。
- すべての Web サービスクライアントは署名されているレスポンスメッセージを受信しなければならないという意味になります。
9.21.2.3.1. クライアント側キーストアの設定 リンクのコピーリンクがクリップボードにコピーされました!
9.21.2.4. BouncyCastle JCE プロバイダーのインストール リンクのコピーリンクがクリップボードにコピーされました!
java.security プロパティファイルにエントリを追加すると静的登録よりプロバイダーを環境の一部として設定することができます。 java.security プロパティセキュリティファイルは、 $JAVA_HOME/jre/lib/security/java.security にあります ($JAVA_HOME は JDK および JRE ディストリビューションの場所に置き換えます)。 このファイルに詳細手順が記載されていますが、 主に次の行を追加することになります。
security.provider.<n>=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.<n>=org.bouncycastle.jce.provider.BouncyCastleProvider
<n> はプロバイダーを配置したい場所になります。
注記
$JAVA_HOME/jre/lib/ext に格納するのがよいでしょう。 ウインドウの下は通常 Java の JRE インストールと JDK インストールになるはずです。 正しくインストールされたにも拘らず動作しない場合は、プロバイダーインストールが使用されていない可能性が高いでしょう。
9.21.2.5. Username Token 認証JBOSSCC-50
リンクのコピーリンクがクリップボードにコピーされました!
例9.1 ユーザー名トークンの基本設定
jboss-wsse-client.xml に貼り付ける必要があります。
jboss-wsse-server.xml ファイルにて同じ<timestamp> 要素と seconds 属性を指定する必要があります。また、<requires/> 要素を指定しこの条件を強化する必要があります。
警告
例9.1「ユーザー名トークンの基本設定」では、平文としてクライアントのパスワードが送信されます。さらにリプレイ攻撃から保護されるようダイジェストパスワード、nonce、タイムスタンプの組み合わせを使うことが可能です。
例9.2 パスワードダイジェストの有効化
jboss-wsse-client.xml ファイルの<username> 要素にて:
digestPassword属性を有効化noncesおよびtimestampsを有効化
login-config.xml ファイルで、Username Token モジュールオプションを実装する必要があります。
例9.3 UsernameTokenCallback モジュール
UsernameTokenCallbackコールバックをログインモジュールにプラグします。org.jboss.security.auth.spi.UsernamePasswordLoginModuleを継承します。- 例9.3「UsernameTokenCallback モジュール」で示されているように、ハッシュ属性 (
hashAlgorithm、hashEncoding、hashUserPassword、hashStorePassword)を設定します。
Nonce が作成され、その後サーバー側でチェック、格納される方法により、リプレイ攻撃に対するセキュリティレベルが左右されます。現在、JBossWS では、サーバー側で受け取ったトークンをキャッシュ化しないという Nonce ストアの基本実装が同梱されています。
NonceFactory と NonceStoreインターフェースを実装することでご利用中のモジュールにより複雑な実装をプラグすることができます。これらのインターフェースorg.jboss.ws.extensions.security.nonceパッケージにあります。
jboss-wsse-server.xml ファイルの<nonce-factory-class> 要素を使ってご利用中のファクトリクラスを指定します。
wsse:Security ヘッダーに Timestamp がある場合、ヘッダー検証にあたり時間比較における誤差の許容範囲はありません。メッセージが少しでも未来の時間に作成されている場合、メッセージの有効期限が切れている場合は拒否されます。 <timestamp-verification>と呼ばれる新しい要素が wsse 設定では利用可能です。例9.4「<timestamp-verification> 設定」 では、<timestamp-verification>要素に必要な属性について説明しています。
例9.4 <timestamp-verification> 設定
createdTolerance- どの程度先のメッセージであれば承認されるか、その秒数。デフォルト値は
0になります。 expiresTolerance- Expired と分類されてからメッセージが拒否されるまでの秒数。デフォルト値は
0になります。 warnCreated- 'Created' が未来の値のメッセージを承認した場合、警告メッセージをログに残すかどうかを指定します。デフォルト値は、
trueです。 warnExpires- 'Expired' の値が過去のメッセージを承認した場合、警告メッセージをログに残すかどうかを指定します。デフォルト値は、
trueです。
注記
warnCreated および warnExpires属性を使い、通常は拒否されているメッセージで承認したものを特定することができます。このデータを使うことで、クライアントのメッセージを拒否することなしにサーバータイムと同期されていないクライアントを特定することができます。
9.21.2.5.1. セキュアトランスポート リンクのコピーリンクがクリップボードにコピーされました!
9.21.2.6. X509 Certificate Token リンクのコピーリンクがクリップボードにコピーされました!
暗号化の設定には、例9.5「X509 暗号化設定」の項目を指定する必要があります。クライアント、サーバーともに同じ設定となります。
例9.5 X509 暗号化設定
- キーストアおよびトラストストア情報:各ストアの場所、パスワード、ストアの種類
- 署名設定:使用する証明書と鍵のペアのエイリアスを提供する必要があります。
includeTimestampは、改竄を防ぐためにtimestamp を署名するか指定します。 - 暗号化設定:使用する証明書とキーのペアのエイリアスを提供する必要があります。詳細については、アルゴリズム を参照してください。
- オプションのセキュリティ要件:受信メッセージは両方、署名、暗号化する必要があります。
複数のクライアントに返信する場合、サービスプロバイダは、正しい公開鍵を使って宛先に基づいて、メッセージを暗号化する必要があります。JBossWS で WS-Security をネーティブ実装すると、受信メッセージで受け取り (確認された) 署名から正しい鍵を取得し利用します。
例9.6 動的暗号化の設定
<encrypt> 要素が宣言されていれば必ず、非対称暗号化および対称暗号化が行われます。生成された対称暗号鍵を使ってメッセージデータを暗号化します。この鍵は、受取側の公開鍵で暗号化 (ラップ)された後に SOAP ヘッダーに書き込まれます。暗号化アルゴリズムとキーラップアルゴリズム両方を設定することが可能です。
- AES 128 (aes-128) (デフォルト)
- AES 192 (aes-192)
- AES 256 (aes-256)
- Triple DES (triple-des)
- RSA v1.5 (rsa_15) (デフォルト)
- RSA OAEP (rsa_oaep)
注記
相互運用できるように、利用する暗号化トークンへの参照タイプを設定する必要があるかもしれません。例えば、ローカルのバイナリセキュリティートークンはJBossWS でデフォルトの参照タイプとして利用されていますが、Microsoft Indigo はこのトークンへの直接参照に対応していません。
tokenReference 属性を指定します。tokenReference 属性の値は以下の通りです:
directReference(デフォルト)keyIdentifier:X509 SubjectKeyIdentifier参照を使いトークンデータを指定します。x509IssuerSerial:X509 とシリアル番号でエンドエンティティ (EE: End Entity) 証明書を一意に識別します。
注記
JBossWS では、署名あるいは暗号化を必要とする要素を正確に制御することができます。これにより、同じサービス上でやりとりがされているが、(e-メールアドレスなど)セキュリティレベルが高くないその他の情報ではなく、重要なデータのみ (クレジットカード番号など) を暗号化することができます。設定方法は、暗号化したい SOAP 要素の修飾名 (qname) を指定します。デフォルトの動作は、SOAP のボディ全体を暗号化します。
XML パーサーが特殊文字を解析する仕方が原因で、キャリッジリターン (\r) を含む署名済みのメッセージペイロードで署名照合エラーが発生する可能性があります。この問題を回避するには、ペイロードを送る前にカスタムエンコーディングを実装するようにします。そうするとユーザーはメッセージを暗号化するか、あるいはJBossWS によりメッセージのメッセージの正準正規化を強制的に行うことができます。
trueに設定されている場合、org.jboss.ws.DOMContentCanonicalNormalization プロパティはペイロードを正規化できます。このプロパティは、クライアント側で呼び出す直前にエンドポイント実装に設定する必要があります。
9.21.2.7. JAAS の統合 リンクのコピーリンクがクリップボードにコピーされました!
Username Token Profile により、呼出し元のユーザー名、パスワードを指定することができます。wsse サーバーの設定ファイルを使って、設定済みのログインモジュールにて認証、権限付与を行う際にこれらの情報を活用することができます。
注記
JBossWS の以前のバージョンでは、指定時は呼出し側の主体と認証情報を設定するために、Username Token が常に使われていました。つまり、<authenticate> 要素が指定され User Token が使われている場合、後方互換ができるようこの動作が残されています。
certificatePrincipal 要素 (1) はクラスを使い X509 証明の属性から主体をリトリーブします。選択したクラスは、CertificatePrincipalを継承する必要があります。属性が指定されていない場合に使うデフォルトのクラスは、org.jboss.security.auth.certs.SubjectDNMappingとなっています。
例9.7 BaseCertLoginModule セキュリティドメイン
CertRolesLoginModule を持つセキュリティドメインのコード例で、(指定のjbossws-roles.properties ファイルを使うことで)認証も有効にします。
org.jboss.security.plugins.JaasSecurityDomain MBean を使ってこのストアを設定します。
例9.8 BaseCertLoginModule キーストア
CertificatePrincipal マッピングクラスは、紐付けられた wsse ヘッダーから取得した主体を使いキーストアにアクセスします。証明書があり、wsse ヘッダーで指定したものと同じであれば、ユーザー認証に成功します。
9.21.2.8. POJO エンドポイント認証および権限付与JBOSSCC-50
リンクのコピーリンクがクリップボードにコピーされました!
重要
手順9.1 POJO 認証や権限付与を有効化
Web アーカイブにてセキュリティドメインを定義
POJO を含む WAR にてセキュリティドメインを定義する必要があります。/WEB-INFフォルダーの jboss-web 配備記述子で<security-domain> を指定します。<jboss-web> <security-domain>java:/jaas/JBossWS</security-domain> </jboss-web>
<jboss-web> <security-domain>java:/jaas/JBossWS</security-domain> </jboss-web>Copy to Clipboard Copied! Toggle word wrap Toggle overflow jboss-wsse-server.xml <authorize> 要素を設定します。
<config> 要素内の<authorize> 要素を指定します。<config> 要素をグローバル、ポート固有、あるいはオペレーション固有のいずれかに定義することが可能です。<authorize> 要素には、<unchecked/> 要素あるいは、1つ以上の<role>要素を含める必要があります。各<role> 要素には、有効な RoleName 名を含む必要があります。認証タイプは、Unchecked と役割ベース認証の2種類から選択し実装することができます。Unchecked 認証この認証手順でユーザーのユーザー名やパスワードを照合しますが、役割の確認はそれ以上行われません。ユーザーのユーザー名やパスワードが無効の場合、リクエストは拒否されます。
例9.9 Unchecked 認証
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 役割ベースの認証Unchecked 認証のようにユーザー名とパスワードを使いユーザー認証が行われます。ユーザーのユーザー名やパスワードが照合されると、ユーザーの認証情報が再確認され、<role> 要素で指定された役割のうち少なくとも1つがユーザーに割り当てられるようにします。
注記
ユーザー名とパスワードあるいは証明書がリクエストメッセージで提示されていない場合でも、認証、権限付与が進められます。このシナリオでは、セキュリティドメインのログインモジュールが匿名のアイデンティティで設定されている場合、認証が進む場合があります。例9.10 役割ベースの認証
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.21.3. XML レジストリ リンクのコピーリンクがクリップボードにコピーされました!
9.21.3.1. Apache jUDDI の設定 リンクのコピーリンクがクリップボードにコピーされました!
allサーバープロファイルの juddi-service.sar アーカイブにデプロイされる MBean Service により行われます。このサービスの設定は juddi-service.sar 内の META-INF ディレクトリにある jboss-service.xml で行うことができます。
<!-- Datasource to Database --> <attribute name="DataSourceUrl">java:/DefaultDS</attribute>
<!-- Datasource to Database -->
<attribute name="DataSourceUrl">java:/DefaultDS</attribute>
9.21.3.2. JBoss JAXR の設定 リンクのコピーリンクがクリップボードにコピーされました!
- クライアントコードが JBoss の内側で実行している場合は (おそらくサーブレットか EJB)、
run.shまたはrun.batのスクリプトにある System プロパティを"-D"オプションを使って java プロセスに渡す必要があります。 - クライアントコードが外部 JVM で実行している場合は、 「-D」オプションとして java プロセスにプロパティを渡すか、 明示的にクライアントコードに設定する (推奨しません) ことができます。
System.setProperty(propertyname, propertyvalue);
System.setProperty(propertyname, propertyvalue);
9.21.3.3. JAXR サンプルコード リンクのコピーリンクがクリップボードにコピーされました!
- J2EE 5.0 JavaDoc の javax.xml.registry.RegistryService より抜粋: 「これは JAXR プロバイダーにより実装される第一インターフェースになります。 レジストリクライアントはこのインターフェースをレジストリへの Connection から取得することができます。 JAXR プロバイダーにより実装される各種の機能固有インターフェースを見つけるためにクライアントによって使用されるメソッドを提供します。」
- J2EE 5.0 JavaDoc の javax.xml.registry.BusinessLifeCycleManager より抜粋: 「Registry Service により公開される BusinessLifeCycleManager インターフェースはビジネスレベル API の一部として Registry のライフサイクル管理機能を実装します。 Connection インターフェースはクライアントの代わりにその状態とコンテキストを維持するため提供される認証情報はないので注意してください。」
- J2EE 5.0 JavaDoc の javax.xml.registry.BusinessQueryManager より抜粋: 「Registry Service により公開される BusinessQueryManager インターフェースはビジネススタイルのクエリーインターフェースを実装します。 集中クエリーインターフェースとも呼ばれます。」
9.21.3.4. トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
- JAXR からレジストリに接続できません。 inquiry を確認して JAXR ConnectionFactory に渡された url を公開してください。
- jUDDI レジストリに接続できません。 jUDDI 設定を確認して server.log にエラーがないかチェックしてください。 また、 jUDDI レジストリは「all」構成でのみ使用可能になるので注意してください。
- jUDDI レジストリに対して認証できません。 章の前半の説明通りに、 認証ユーザーを jUDDI データベースに追加しましたか?
- クライアントと UDDI レジストリの間を移動中の SOAP メッセージを表示させたいのですが。 tcpmon ツールを使って移動中のメッセージを表示してください。 TCPMon
9.21.3.5. リソース リンクのコピーリンクがクリップボードにコピーされました!
9.22. JBossWS の拡張 リンクのコピーリンクがクリップボードにコピーされました!
9.22.1. 登録商標のアノテーション リンクのコピーリンクがクリップボードにコピーされました!
9.22.1.1. EndpointConfig リンクのコピーリンクがクリップボードにコピーされました!
9.22.1.2. WebContext リンクのコピーリンクがクリップボードにコピーされました!
9.22.1.3. SecurityDomain リンクのコピーリンクがクリップボードにコピーされました!
9.23. Web サービス付録 リンクのコピーリンクがクリップボードにコピーされました!
注記
第10章 JBoss AOP リンクのコピーリンクがクリップボードにコピーされました!
10.1. 主な用語 リンクのコピーリンクがクリップボードにコピーされました!
ジョインポイントとは Java プログラム内のポイントのことです。 メソッドの呼び出し、 コンストラクタの実行、 フィールドのアクセスはすべてジョインポイントとなります。 ジョインポイントは、 イベントがメソッド呼び出し、 コンストラクタコール、 フィールドアクセスなどである特定の Java イベントと考えることができます。
呼び出しは、 ランタイム時のジョインポイントをカプセル化する JBoss AOP クラスです。 呼び出されたメソッドやメソッドの引数などの情報が含まれます。
アドバイスは、 特定のジョインポイントが実行された時に呼び出されるメソッドのことです (メソッドが呼び出された時にトリガーされる動作など)。 インターセプションを行うコードと考えることもできます。 アドバイスは「イベントハンドラー」とも類似しています。
ポイントカットは AOP の表現言語です。 正規表現が文字列と一致するように、 ポイントカット表現もジョインポイントと一致します。
イントロダクションは Java クラスのタイプや構造を変更します。 既存のクラスにインターフェースを実装するよう強制、あるいは アノテーションを追加するために使用できます。
アスペクトは、 アドバイス、 ポイントカット定義、 ミックスイン、 その他 JBoss AOP コンストラクトの数をカプセル化するプレーン Java クラスです。
インターセプターは invoke という名前のアドバイスのみを持つアスペクトです。 インターフェースを実装するようクラスを強制してコードをチェックしたい場合に実装できるインターフェースです。 インターセプターは移植可能で、 EJB や JMX MBean など他の JBoss 環境で再使用することができます。
try/finallyブロックのコードを手作業でベンチマーク対象のメソッドやコンストラクターすべてに追加する必要があるため、 メトリクスの有効化や無効化が大変難しくなります。- プロファイリングコードをアプリケーション全体に散在させるべきではありません。
try/finallyブロック内にタイミングが含まれるようにしなければならないため、 コードが膨張して読みにくくなります。 - この機能を拡張してメソッドや失敗数が含まれるようにし、 これらの統計を高性能なレポートメカニズムに登録したい場合、 多くのファイルを変更する必要があります。
BankAccountDAO への呼び出しがメトリクスアスペクトを通過するよう指定するププログラム制御を AOP は提供します。
10.2. JBoss AOP でアスペクトを作成 リンクのコピーリンクがクリップボードにコピーされました!
BankAccountDAO.withdraw() メソッドにある try/finally ブロックを JBoss AOP インターセプタークラスの実装である Metrics に抽出します。
withdraw()をラップします。 呼び出しコードが withdraw() を呼び出すと、 AOP フレームワークがメソッドコールをパーツに分解し、 パーツを呼び出しオブジェクトにカプセル化します。 その後、 呼び出しコードと実際のメソッドボディーの間に存在するすべてのアスペクトをフレームワークが呼び出します。
Metricsの呼び出しメソッドを呼び出します。 8 行目は実際のメソッドをラップし、実際のメソッドへ委譲します。try/finally ブロックを使用してタイミングを実行します。 13 行目は Invocation オブジェクトからメソッドコールのコンテキスト情報を取得します。 14 行目はメソッド名と算出されたメトリクスを表示します。
Metrics コードが存在することにより、後で追加の測定を簡単に拡張し取得することができます。アスペクトにカプセル化されたメトリクスの適用方法を見てみましょう。
10.3. JBoss AOP でアスペクトを適応 リンクのコピーリンクがクリップボードにコピーされました!
executeQuery() への呼び出しに対し、SQL 構文を検証するアスペクトを呼び出す」のようになります。
interceptor クラスへの インターセプター名のマッピングを定義しています。2-4 行目は、特定のBankAccountDAO.withdraw() メソッドに metrics アスペクトを適用するポイントカットを定義します。5-7 行目は com.mc.billing パッケージにおける全クラスの全メソッドへ metrics アスペクトを適用する一般的なポイントカットを定義します。XML を希望しない場合は、オプションのアノテーションマッピングもあります。詳細は JBoss AOP の参照文書をご覧ください。
BankAccountDAO クラス内のコードはプロファイルされた事を認識しません。 プロファイリングはアスペクト指向プログラマーが直交した関心事 (orthogonal concern) として考えるものの一部です。 本章の始めにあるオブジェクト指向プログラミングのコードスニペットでは、 プロファイリングがアプリケーションコードの一部となっています。 AOP ではこのコードを削除することが可能です。 近年のミドルウェアは透明性を約束していますが、 AOP も確実に透明性を提供します。
10.4. AOP アプリケーションのパッケージ リンクのコピーリンクがクリップボードにコピーされました!
*-aop.xml とパッケージと共に直接 deploy/ ディレクトリにデプロイするか (これにより jboss-aop.deployer ファイルにある base-aop.xml が利用できます)、 クラスを格納する JAR ファイルに XML ファイルが含まれるようにすることができます。 JAR に XML ファイルが含まれるようにする場合、 ファイルの拡張子は .aop でなければなりません。 また、jboss-aop.xml ファイルは META-INF ディレクトリに含まれなければなりません (例: META-INF/jboss-aop.xml)。
xmlns="urn:jboss:aop-beans:1:0 属性をルート aop 要素に追加します。
<aop xmlns="urn:jboss:aop-beans:1.0"> </aop>
<aop xmlns="urn:jboss:aop-beans:1.0">
</aop>
.aop JAR ファイルを使った既定の例を超えるものを作成するには、XML バインディング設定を格納する AOP ファイルが含まれるトップレベルのデプロイメントを作成します。 例えば、EAR ファイルまたは WAR ファイルに AOP ファイルを保持することができます。 AOP ファイル内にある META-INF/jboss-aop.xml ファイルに指定されたバインディングは、 WAR ファイル全体のすべてのクラスに影響します。
.ear/META-INF/application.xml にリストされなければなりません。
重要
.ear ファイルの内容は application.xml にある一覧の順番通りにデプロイされます。 ロード時の組み入れを使用する場合は、 ejb クラスや servlet などがロードされる前にバインディングがシステムに存在するよう、 アドバイスされたクラスがデプロイされる前に example.aop ファイルにリストされているバインディングがデプロイされなければなりません。 これには、 application.xml の最初に AOP ファイルを記載します。 .sar ファイルや .war ファイルなど、 他のタイプのアーカイブは最初にデプロイされるため、 特別な処置は必要ありません。
10.5. JBoss AspectManager サービス リンクのコピーリンクがクリップボードにコピーされました!
AspectManager サービスは、 http://localhost:8080/jmx-console の JMX コンソールを使用してランタイム時に管理することができます。 AspectManager サービスは ObjectName jboss.aop:service=AspectManager で登録されています。 起動時に設定を行いたい場合は、 設定ファイルを編集する必要があります。
AspectManager サービスは JBoss Microcontainer bean を使用して設定されます。 設定ファイルは jboss-as/server/PROFILE/conf/bootstrap/aop.xml です。 AspectManager サービスは次の XML にてデプロイされます。
AspectManager サービスのクラス変更については後ほど説明します。 クラスを変更するには、 bean 要素の class 属性の内容を置き換えます。
10.6. Sun JDK を使用した JBoss Enterprise Application Platform におけるロード時の変換 リンクのコピーリンクがクリップボードにコピーされました!
enableLoadtimeWeaving属性/プロパティをtrueに設定します。 JBoss Application Server はデフォルトでは AOP ファイルのロード時のバイトコード操作を実行しないため、 この設定を行う必要があります。suppressTransformationErrorsがtrueに設定されている場合、 バイトコード変換に失敗するとエラー警告のみが生成されます。 JBoss デプロイメントにクラスが参照する全てのクラスが存在しないことがあるため、 このフラグが必要となります。pluggable-instrumentor.jarを JBoss AOP ディストリビューションのlib/ディレクトリから JBoss Enterprise Application Platform のbin/ディレクトリへコピーします。- 次に
run.shまたはrun.bat(OS によって異なります) を編集し、 下記をJAVA_OPTS環境変数に追加します。set JAVA_OPTS=%JAVA_OPTS% -Dprogram.name=%PROGNAME% -javaagent:pluggable-instrumentor.jar
set JAVA_OPTS=%JAVA_OPTS% -Dprogram.name=%PROGNAME% -javaagent:pluggable-instrumentor.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow
重要
-javaagent オプションが機能する org.jboss.aop.deployers.AspectManagerJDK5 または org.jboss.aop.deployment.AspectManagerServiceJDK5 でなければなりません。
10.7. JRockit リンクのコピーリンクがクリップボードにコピーされました!
-javaagent スイッチもサポートします。 このスイッチを使用する場合、 「Sun JDK を使用した JBoss Enterprise Application Platform におけるロード時の変換」 の手順に従ってください。 JRockit はクラスがロードされる際のインターセプトに対する独自のフレームワークも持っており、 -javaagent スイッチよりも高速である場合があります。 特別な JRockit フックを使用してロード時の変換を実行する場合は、 次の手順に従ってください。
enableLoadtimeWeaving属性/プロパティを true に設定します。 JBoss アプリケーションサーバーはデフォルトでは AOP ファイルのロード時のバイトコード操作を実行しないため、 この設定を行う必要があります。suppressTransformationErrorsに設定されている場合、 バイトコード変換に失敗するとエラー警告のみが生成されます。 JBoss デプロイメントにクラスが参照する全てのクラスが存在しないことがあるため、 このフラグが必要となります。jrockit-pluggable-instrumentor.jarを JBoss AOP ディストリビューションのlib/ディレクトリから JBoss Enterprise Application Platform のbin/ディレクトリへコピーします。- 次に
run.shまたはrun.bat(OS によって異なります) を編集し、 下記をJAVA_OPTS環境変数とJBOSS_CLASSPATH環境変数に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JRockit の特別なフックに対応するため、
AspectManagerサービスのクラスを JBoss Enterprise Application Platform 5 上でorg.jboss.aop.deployers.AspectManagerJRockitに設定するか、org.jboss.aop.deployment.AspectManagerServiceに設定します。
10.8. JBoss Enterprise Application Platform 環境でロード時のパフォーマンスを改善 リンクのコピーリンクがクリップボードにコピーされました!
jboss-5.x.x.GA/server/xxx/conf/aop.xml ファイルより設定できます。
10.9. AOP をクラスローダーへスコープ リンクのコピーリンクがクリップボードにコピーされました!
10.9.1. スコープされたクラスローダーの一部としてデプロイ リンクのコピーリンクがクリップボードにコピーされました!
.aop/META-INF/jboss-aop.xml ファイル内に適用されるバインディングなどは、スクープされたアーカイブ内でクラスのみに適用され、 アプリケーションサーバーのそれ以外のものには適用されません。 -aop.xml ファイルをサービスアーカイブ( SAR) の一部としてデプロイする方法もあります。 この場合でも、 SAR がスコープされていると、 -aop.xml ファイルに格納されたバインディングは SAR ファイルの内容のみに適用されます。 現在、 スタンドアローンの -aop.xml ファイルをデプロイあるいは、すでに添付されたデプロイメントに添付することはできません。 スタンドアロン -aop.xml ファイルはアプリケーションサーバー全体のクラスに適用されます。
10.9.2. スコープされたデプロイメントへ添付 リンクのコピーリンクがクリップボードにコピーされました!
jboss-app.xml ファイルを使用しスコープされた EAR ファイルとスコープされたローダーレポジトリ jboss.test:service=scoped があるとします。
META-INF/jboss-aop.xml> にある loader-repository を使用します。
第11章 トランザクション管理 リンクのコピーリンクがクリップボードにコピーされました!
11.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
- JBoss Transaction Service JTS
- トランザクションマネージャーは、リモート IIOP メソッドの呼び出し上でトランザクションコンテキストを分散でき、複数の JVM に対応する単一の分散トランザクションを作成することができます。 複数のサーバーにわたる大型のアプリケーションや、 CORBA ベースのシステムで実行されているトランザクションビジネスロジックとの規格ベースの相互運用に対して有用です。このモジュールの機能は標準的なJTA API から利用できるため、トランザクションビジネスロジックへの変更を必要とせず、 簡単に代わりの導入ができます。この機能の有効化に関する詳細情報は「JTS Module の利用」 を参照してください。
- JBoss Transaction Service XTS
- WS-AtomicTransaction (WS-AT) や WS-BusinessActivity (WS-BA) 仕様を実装する XML ベースの Transaction Manager です。 この追加モジュールは JTA または JTS が提供するコアトランザクションサポートや JBossWS Native が提供する Web サービス機能は使用します。JBossTransaction Service XTS はアプリケーションとしてサーバー内にデプロイされます。 アプリケーションは JTS とほぼ同じ要領で WS-AT を使用して標準的な分散 ACID トランザクションを提供することもありますが、 CORBA ではなく Web サービストランスポートを使用します。 WS-BA 実装は、さらに代替の補償ベーストランザクションモデルを提供します。 このトランザクションモデルは、長期実行される疎結合のビジネスプロセスの調整に適しています 。XTS は、 通常はローカル WS-AT 実装や WS-BA 実装が内部でのみアクセスする WS-Coordination (WS-C) サービスも実装します。しかし、この WS-C サービスは、 別の JBoss サーバーインスタンスや JBoss 以外のコンテナに作成された WS-AT や WS-BA トランザクションのリモート調整を提供するためにも使用されます。XTS を有効にするには、「XTS モジュールの利用」 を参照してください。
11.2. 必須設定 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/conf/jbossts-properties.xml にあります。 設定ファイルには、 最も一般的に使用されるプロパティのデフォルト設定が格納されています。 その他の設定について多数、付属の JBossTransaction Service 管理ガイドに説明されています。各設定にはハードコードされたデフォルトがありますが、設定ファイルがないとシステムが正しく機能しない場合があります。追加設定は$JBOSS_HOME/server/PROFILE/deploy/transaction-jboss-beans.xml にある Microcontainer bean 設定の一部として行うこともできます。これにより、 トランザクションマネージャーがサーバープロファイル全体の設定に結合されるため、随時トランザクション設定ファイルの設定よりもアプリケーションサーバー固有の値が優先されます。 特に、Service Binding Manager を使用してポートのバインディグ情報を設定し、選択された他のプロパティより優先させます。 設定プロパティはサーバーの初期化時に JBossTransaction Service によって読み取られ、 その後設定ファイルに加えられた変更は、 サーバーが再起動するまで有効になりません。
|
プロパティ名
|
デフォルト値
|
詳細
|
|---|---|---|
|
transactionTimeout
|
300 秒
|
秒単位のデフォルト時間で、この時間が経過した後トランザクションはタイムアウトし、ロールバックされます。ご利用中の環境やワークロードにあわせて、これを調節してください。
トランザクションが非同期的に処理される点に驚かれるかもしれませんが、設計的にこのように決定され、コードによりユーザ側で対応する必要があります。
|
|
objectStoreDir
| |
トランザクションデータがログ化されるディレクトリ。システム障害が発生した場合にトランザクションを完了するにはトランザクションログが必要となり、このログは信頼性のあるストレージに設置される必要があります。通常、トランザクション毎に1ファイル生成され、各ファイルはサイズ的には数キロバイトとなっています。パフォーマンスが最適化されるよう、これらのファイルはディレクトリツリー全体で分散されています。RAIDコントローラを使っている場合、データベースの格納デバイスとほぼ同じ方法でライトスルーキャッシュ用に設定する必要があります。トランザクションがロールバックされる場合あるいは、リソースを1つしか含まない場合、トランザクションログの書き込みは自動的にスキップされます。
|
|
max-pool-size
| |
Java EE Connector Architectureコンテナは、リカバリが実行されるEISに対し、専用の物理接続を開いた状態に保ちます。そのため、
max-pool-size を(接続可能な最大数ー1)を設定してください。
|
|
プロパティ名
|
デフォルト値
|
詳細
|
|---|---|---|
|
com.arjuna.common.util.logging.DebugLevel
| 0x00000000 はロギングなしと同等。
|
トランザクションマネージャーのコードベースに対する内部ログの閾値を決定します。サーバー全体の log4j ロギング設定から独立しており、外部からのログ入力が表示されないように抑える役割を果たします。デフォルト値が有効であれば、INFO や WARN メッセージは表示され、この設定により最適なパフォーマンスが実現されます。
0xffffffff により完全なデバッグロギングが有効になり、この設定をするとログファイルのサイズが大きくなります。
内部の
DebugLevel チェックを渡すログメッセージがサーバーのロギングシステムに渡されさらに処理されます。理論的には、完全なデバッグ機能はオンの状態にでき、log4j を使ってロギングの切/入が可能ですが、実際にはこれはパフォーマンスに影響を与えます。
|
|
com.arjuna.ats.arjuna.coordinator.commitOnePhase
| YES
|
トランザクションに単一のリソースのみが登録されている場合に、トランザクションマネージャーは自動的に1フェーズコミットの最適化をトランザクション完了プロトコルへ適用しするかを決定します。デフォルトでは、トランザクションログの書き込みを回避するため、この設定は有効になっています。
|
|
com.arjuna.ats.arjuna.objectstore.transactionSync
| ON
|
この設定は、 トランザクションの終了中にディスクへのトランザクションログのフラッシングを制御します。 デフォルト値では、各コミットトランザクションに対して
FileDescriptor.sync 呼び出しが実行されます。リカバリ保証や ACID プロパティの提供に、この動作は必要となります。これらの機能がアプリケーションにとって重要でない場合、このプロパティを向こうにすることでパフォーマンスが向上しますが、通常、トランザクションを全く利用しないようにアプリケーションを記述するほうが良いため、この方法は推奨されません。
|
|
com.arjuna.ats.arjuna.xa.nodeIdentifier
com.arjuna.ats.jta.xaRecoveryNode
| |
これらのプロパティはトランザクションリカバリシステムの動作を決定します。 サーバーのクラッシュが発生した時にリカバリが行われトランザクションが正しく解決されるようにするため、 適切な設定が必要となります。 詳細は、JBoss Transaction 管理ガイドの リカバリの章を参照してください。
|
|
com.arjuna.ats.arjuna.coordinator.enableStatistics
| NO
|
トランザクション統計の収集を有効にします。この統計は、
FileDescriptor.sync あるいは該当の JMX MBean でメソッドを使うことで参照できます。デフォルトでは無効になっています。
|
11.3. トランザクションリソース リンクのコピーリンクがクリップボードにコピーされました!
XAResource 実装を利用しトランザクションステートの更新を調整します。 リソースマネージャーは、 データベース、 メッセージキュー、 サードパーティ JCA リソースアダプターなどを含むことがあります。 JBoss Enterprise Application Platform での使用が認定された JDBC データベースドライバーやデータベースの一覧は http://www.jboss.com/products/platforms/application/supportedconfigurations/ を参照してください。 規格準拠の JDBC ドライバーの多くは正しく機能するはずですが、ベンダーによって XA 仕様の解釈が異なるため、認定を受けていないドライバーを使う場合は徹底的なテストを行う必要があります。
-ds.xml などのファイル名にします。<xa-datasource> プロパティを使うデータソースは自動的にトランザクションマネージャーとやりとりを行います。JNDI でこのようなデータソースを検索し、 getConnection を呼び出すことで取得した接続は自動的に進行中のトランザクションに参加します。これは、データアクセスに対してトランザクション保証が必要な場合、推奨されるユースケースとなっています。
11.4. 最終リソースコミット最適化 (LRCO: Last Resource Commit Optimization) リンクのコピーリンクがクリップボードにコピーされました!
prepare フェーズの最後に処理され、その時にコミットが試行されます。コミットに成功すると、トランザクションログが書き込まれ、残りのリソースはフェーズ 2 コミットに進みます。最後のリソースのコミットに失敗すると、トランザクションはロールバックされます。このプロトコルにより、 ほとんどのトランザクションは普通通りに完了しますが、エラーの種類によっては不整合なトランザクション結果が生じる原因となります。そのため、 他に手段がない場合のみ LRCO を使ってください。トランザクションに単一の <local-tx-datasource> が使用される場合、LRCO が自動的に適用されます。その他の場合、特別なマーカーインターフェースを使用して最終リソースを指定することが可能です。詳細は JBoss Transactions のプログラマーガイドを参照してください。
11.5. トランザクションタイムアウトの処理 リンクのコピーリンクがクリップボードにコピーされました!
TransactionReaper が調整するバックグラウンドプロセスのセットによって停止が実行されます。リーパーは、範囲内で動作している可能性があるスレッドへ割り込まずにトランザクションをロールバックします。これにより、任意コードを実行するスレッドへの割り込みが原因で発生する不安定性を防ぐことができます。また、ビジネスロジックスレッドがネットワーク I/O 呼び出しなど割り込みできない操作を実行している場合、トランザクションを適時に停止できるようにします。 しかし、 この方法はマルチスレッド化されたトランザクションの処理を想定していないコードで、 予想外の動作が実行される原因となることがあります。予想外のトランザクション状況の変化により、他のトランザクション対応コンポーネントなどから警告やエラーメッセージが出力されることがありますが、 トランザクションの結果へは影響しないはずです。トランザクションタイムアウトの値を適切に調節することでこの問題を最小限に抑えることができます。詳細については、15章DataSource の設定 を参照してください。
11.6. リカバリ設定 リンクのコピーリンクがクリップボードにコピーされました!
11.7. Transaction Service のよくある質問 リンクのコピーリンクがクリップボードにコピーされました!
- 問: デバッグロギングを有効にしましたが何もログに残されていません。
- 問: サーバーログに WARN Adding multiple last resources is disallowed. が表示されトランザクションが停止されました。なぜでしょうか。
- 問: サーバーが予期せず停止しました。現在、再稼働していますが、 ログに次のようなメッセージが記録されています: WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource.
- 問: トランザクションに時間がかかり、 時々予期しないことが発生します。 サーバーログには次が含まれています: WARN [arjLoggerI18N] [BasicAction_58] - Abort of action id ... invoked while multiple threads active within it.
- ログは、JBoss Transaction Service の独自のロギング抽象層を経由します。
- ログは、JBoss Enterprise Application Platform's
log4jのロギングシステムを経由します。
WARN Adding multiple last resources is disallowed. が表示されトランザクションが停止されました。なぜでしょうか。
WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource.
WARN [arjLoggerI18N] [BasicAction_58] - Abort of action id ... invoked while multiple threads active within it.
11.8. JTS Module の利用 リンクのコピーリンクがクリップボードにコピーされました!
jbossts-properties.xml ファイルを変更するだけです。
jbossts-properties.xml ファイルは、$JBOSS_HOME/docs/examples/transactions/ ディレクトリに置かれています。 transactions-jboss-beans.xml など、他のファイルに加える必要のある変更については、同じディレクトリにある README.txt を参照してください。全ステップを自動で実行するために、ANT スクリプトが提供されていますが、このスクリプトを実行する前に README.txt を注意して参照していただき、既存の設定のバックアップを取るよう推奨しています。
INFO [TransactionManagerService] JBossTS Transaction Service (JTA version - ...)
INFO [TransactionManagerService] JBossTS Transaction Service (JTA version - ...)
INFO [TransactionManagerService] JBossTS Transaction Service (JTS version - ...)
INFO [TransactionManagerService] JBossTS Transaction Service (JTS version - ...)
11.9. XTS モジュールの利用 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/docs/examples/transactions/ に Service Archive (.sar) としてパッケージ化されています。
手順11.1 XTS モジュールのインストール
jbossxts.sar/と呼ばれる$JBOSS_HOME/server/[name]/deploy/ディレクトリ にサブディレクトリを作成します。- この新しいディレクトリに、ZIP アーカイブの .sar を解凍します。
- JBoss Enterprise Application Platform を再起動し、このモジュールを有効にします。
注記
jbossxts-api.jar にリンクすることもできますが、クラスローディングの問題を回避するにはこのファイルをご利用中のアプリケーションとパッケージ化するべきではありません。これ以外の JAR ファイルにはすべて内部実装クラスが含まれているため、直接利用するべきではありません。
$JBOSS_HOME/docs/examples/transactions/README.txtをご覧ください。JBoss Web Services Transactions ユーザーガイドには、ご利用中のアプリケーションでの XTS 利用に関する情報が含まれています。
11.10. トランザクション管理コンソール リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/docs/example/transactions/ に含まれる簡単な GUI ツールですが、これは未対応で試験的なプロトタイプとして提供されています。Transaction Management Console の機能や、用途に関する情報は、README.txt を参照してください。
11.11. コンポーネント (トライアル) リンクのコピーリンクがクリップボードにコピーされました!
警告
- txbridge
- Web Services トランザクションの範囲内で、EJB といった従来のトランザクションコンポーネントを呼び出す機能が必要な場合もあります。反対に従来のトランザクション系アプリケーションによっては、トランザクショナルな Web サービスを呼び出す必要がある可能性もあります。Transaction Bridge (txbridge) は、この2種類のトランザクショナルサービスを連携する仕組みを提供しています。
- BA フレームワーク
- XTS API は、非常に低いレベルで稼働しており、開発者は WS-BA を絡めたトランザクションインフラストラクチャーの作業を行う必要があります。BA フレームワークは、ハイレベルのアノテーションを用意しており、JBoss Transaction Service がこのようなインフラストラクチャーに対応できるようにしています。そのため、開発者は、ビジネスロジックにさらに焦点をあてることができます。
11.12. ソースコードとアップグレード リンクのコピーリンクがクリップボードにコピーされました!
INFO [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA_CP02) - JBoss Inc.
INFO [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA_CP02) - JBoss Inc.
tag 要素は、Subversion レポジトリの /tags/ 以下のツリーに対応します。バージョンは、Enterprise Application Platform 自体のバージョンではなく、 Enterprise Application Platform にて利用される JBoss Transaction Service コンポーネントのバージョンであることに注意してください。ソースから Enterprise Application Platform を構築する場合は、component-matix/pom.xmlファイルの文字列 version.jboss.jbossts を検索しバージョンを確認することができます。
警告
第12章 リモーティング リンクのコピーリンクがクリップボードにコピーされました!
12.1. 背景 リンクのコピーリンクがクリップボードにコピーされました!
socket://bluemonkeydiamond.com:8888/?timeout=10000&serialization=jboss
socket://bluemonkeydiamond.com:8888/?timeout=10000&serialization=jboss
12.2. JBoss Remoting の設定 リンクのコピーリンクがクリップボードにコピーされました!
12.2.1. MBean リンクのコピーリンクがクリップボードにコピーされました!
- このサーバーは bisocket トランスポートを使用
- ホスト ${jboss.bind.address}; の 4457 番ポートで稼働
- JBoss Messaging は独自のマーシャリングアルゴリズムを使用
bisocket://bluemonkeydiamond.com:4457/?marshaller=
org.jboss.jms.wireformat.JMSWireFormat&
unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
bisocket://bluemonkeydiamond.com:4457/?marshaller=
org.jboss.jms.wireformat.JMSWireFormat&
unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
12.2.2. POJO リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.remoting.ServerConfiguration POJO のように同じコネクターを設定することができます。
ServerConfiguration POJO に表現され、 JBMConnector org.jboss.remoting.transport.Connector POJO に挿入されます。構文は Microcontainer の構文ですが、本章の範囲外となりますので、詳細は 7章マイクロコンテナー を参照してください。また、MBean バージョンのバリエーションの 1 つが ServiceBindingManager の使用になりますが、これも本章の範囲外となります。@org.jboss.aop.microcontainer.aspects.jmx.JMX アノテーションによって、JBMConnector が「jboss.messaging:service=Connector,transport=bisocket」という名前の MBean として表示されるようになります。
12.3. マルチホーム化されたサーバー リンクのコピーリンクがクリップボードにコピーされました!
<entry>
<key>homes</key>
<value><value-factory bean="homes2" method="toString"/></value>
</entry>
<entry>
<key>homes</key>
<value><value-factory bean="homes2" method="toString"/></value>
</entry>
bisocket://multihome/?homes=external.acme.com:5555!internal.acme.com:
4444&marshaller=org.jboss.jms.wireformat.JMSWireFormat&
unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
bisocket://multihome/?homes=external.acme.com:5555!internal.acme.com:
4444&marshaller=org.jboss.jms.wireformat.JMSWireFormat&
unmarshaller=org.jboss.jms.wireformat.JMSWireFormat
12.4. アドレス変換 リンクのコピーリンクがクリップボードにコピーされました!
12.5. 設定ファイルの場所 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/$CONFIG/deploy/remoting-jboss-beans.xml
$JBOSS_HOME/server/$CONFIG/deploy/ejb3-connectors-jboss-beans.xml
$JBOSS_HOME/server/$CONFIG/deploy/messaging/remoting-bisocket-service.xml
12.6. 詳細情報 リンクのコピーリンクがクリップボードにコピーされました!
第13章 JBoss Messaging リンクのコピーリンクがクリップボードにコピーされました!
第14章 JBoss Enterprise Application Platform で別のデータベースを使用 リンクのコピーリンクがクリップボードにコピーされました!
14.1. 代わりのデータベースの使用法 リンクのコピーリンクがクリップボードにコピーされました!
14.2. JDBC ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/lib ディレクトリに設置する必要があります。また、 PROFILE を利用予定のサーバープロファイルで置き換えます。
JBDC ドライバーのダウンロード先
- MySQL
- PostgreSQL
- http://jdbc.postgresql.org/ からダウンロード
- Oracle
- IBM
- Sybase
- Sybase jConnect 製品ページ http://www.sybase.com/products/allproductsa-z/softwaredeveloperkit/jconnect からダウンロード
注記
このドライバーで Sybase データベースを使うと、ドライバーのPreparedStatementクラスでの制限が原因でMaxParams属性を481以上に設定することができません。 - Microsoft
- MSDN Web サイト http://msdn.microsoft.com/data/jdbc/ からダウンロード
14.2.1. Sybase に関する注記 リンクのコピーリンクがクリップボードにコピーされました!
sp_dboption db_name, "allow nulls by default", true
sp_dboption db_name, "allow nulls by default", true
@@textsize のグローバル変数で決定されます。この変数のデフォルト設定は、Adaptive Server へアクセスするのに利用するソフトウェアによって変わります。JDBC ドライバーについては、デフォルト値は 32 キロバイトとなっています。
14.2.1.1. JAVA サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
sp_configure "enable java",1
sp_configure "enable java",1
com.sybase.jdbc2.jdbc.SybSQLException: Cannot run this command because Java services are not
enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java
com.sybase.jdbc2.jdbc.SybSQLException: Cannot run this command because Java services are not
enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java
14.2.1.2. CMP の設定 リンクのコピーリンクがクリップボードにコピーされました!
sysxtypes には、各拡張 Java-SQL データタイプに対して 1 つの行が含まれており、このテーブルは、Java が有効な Adaptive Server のみに利用されます。Java のために有効になっている Adaptive Server のみに使用されます。installjava プログラムを使用して java クラスをインストールしてください。
installjava -f <jar-file-name> -S<sybase-server> -U<super-user> -P<super-pass> -D<db-name>
installjava -f <jar-file-name> -S<sybase-server> -U<super-user> -P<super-pass> -D<db-name>
14.2.1.3. Java クラスのインストール リンクのコピーリンクがクリップボードにコピーされました!
- Java クラスをインストールするには、必要な権限を持つスーパーユーザーになる必要があります。
- インストールする JAR ファイルは圧縮せずに作成する必要があります。
- インストールしてサーバー内で使用する Java クラスは JDK 1.2.2 でコンパイル されている必要があります。より新しい JDK で1つのクラスをコンパイルしても、 installjava ユーティリティを使用してサーバーにインストールできますが、 そのクラスの使用を試す時に、 java.lang.ClassFormatError 例外が発生します。 これは、Sybase Adaptive Server が内部で古い JVM を使用しているため、 それと同じもので Java クラスをコンパイルする必要があるからです。
14.2.1.4. Sybase v15.0.3 向けにデフォルトの @@textsize を増加 リンクのコピーリンクがクリップボードにコピーされました!
@@textsize を 32768 (バイト) から 2147483647 (バイト) に変更してください。
sybase-ds.xml に変更を加えます。サンプルの sybase-ds.xml ファイルは、JBOSS_DIST/jboss-as/docs/examples/jca/ に置かれています。
重要
<connection-url>jdbc:sybase:[domain]:[port]/db_name?SQLINITSTRING=set TextSize 2147483647</connection-url>
<connection-url>jdbc:sybase:[domain]:[port]/db_name?SQLINITSTRING=set TextSize 2147483647</connection-url>
14.2.2. JDBC DataSource の設定 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/deploy ディレクトリに設置する必要があります。このファイルは、DBNAME-ds.xmlの標準ネーミングスキームを使います。
$JBOSS_HOME/docs/examples/jca ディレクトリに保存されています。ご利用中のデータベースに対応するデータソースを編集し、アプリケーションサーバーを再起動する前にdeploy/ ディレクトリにコピーします。
connection-url、user-name、password を変更する必要があります。
14.3. 一般的なデータベース関連のタスク リンクのコピーリンクがクリップボードにコピーされました!
14.3.1. セキュリティとプーリング リンクのコピーリンクがクリップボードにコピーされました!
ResourceAdapter に <reauthentication-support> がある場合を除き、 複数のセキュリティ ID を使用すると各 ID に対してサブプールが作成されます。
注記
14.3.2. JMS サービス用にデータベースを変更 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/deploy/messaging/$DATABASE-persistence-service.xml をファイル $DATABASE-persistence-service.xml に置き換える必要があります。
- MySQL:
mysql-persistence-service.xml - PostgreSQL:
postgresql-persistence-service.xml - Oracle:
oracle-persistence-service.xml - DB2:
db2-persistence-service.xml - Sybase:
sybase-persistence-service.xml - MS SQL Server:
mssql-persistence-service.xml
14.3.3. CMP サービスで外部キーのサポート リンクのコピーリンクがクリップボードにコピーされました!
fk-constraint プロパティが true になるよう、$JBOSS_HOME/server/PROFILE/conf/standardjbosscmp-jdbc.xml ファイルを変更する必要があります。 JBoss Enterprise Application Platform 上でサポートする全ての外部データベースに対して変更する必要があります。 このファイルは、 JBoss Enterprise Application Platform にデプロイされた EJB2 CMP Bean のデータベース接続設定を構成します。
<fk-constraint>true</fk-constraint>
<fk-constraint>true</fk-constraint>
14.3.4. Java Persistence API 用にデータベースダイアレクトを指定 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/PROFILE/deployers/ejb3.deployer/META-INF/jpa-deployers-jboss-beans.xml ファイルにデータベースファイルを設定することができます。 このファイルを設定するには、 マップエントリ hibernate.dialect に関連するタグセットをアンコメントし、 設定するデータベースに応じて次の値に変更する必要があります。
- Oracle 10g:
org.hibernate.dialect.Oracle10gDialect - Oracle 11g:
org.hibernate.dialect.Oracle10gDialect - Microsoft SQL Server 2005:
org.hibernate.dialect.SQLServerDialect - Microsoft SQL Server 2008:
org.hibernate.dialect.SQLServerDialect - PostgresSQL 8.2.3:
org.hibernate.dialect.PostgreSQLDialect - PostgresSQL 8.3.7:
org.hibernate.dialect.PostgreSQLDialect - MySQL 5.0:
org.hibernate.dialect.MySQL5InnoDBDialect - MySQL 5.1:
org.hibernate.dialect.MySQL5InnoDBDialect - DB2 9.1:
org.hibernate.dialect.DB2Dialect - Sybase ASE 15:
org.hibernate.dialect.SybaseASE15Dialect
14.3.5. 外部データベースを使用するよう他の JBoss Enterprise Application Platform サービスを変更 リンクのコピーリンクがクリップボードにコピーされました!
14.3.5.1. 簡単な方法 リンクのコピーリンクがクリップボードにコピーされました!
DefaultDS に変更することです。ほとんどの JBoss サービスはデフォルトで DefaultDS を使用するように設定されています。そのため、 DataSource 名を変更するだけで、 各サービス用に個別設定を変更する必要はありません。
*-ds.xml ファイルを開き、 jndi-name プロパティの値を DefaultDS に変更します。 例えば、 mysql-ds.xml では、 MySqlDS を DefaultDS などに変更することになります。 この後、 DefaultDS 定義の重複を避けるために、 $JBOSS_HOME/server/PROFILE/deploy/hsqldb-ds.xml ファイルを削除する必要があります。
messaging/$DATABASE-persistence-service.xml ファイルでは、PersistenceManagers MBean の depends タグのデータソース名も DefaultDS に変更する必要があります。例えば、mysql-persistence-service.xml ファイルの場合、MySqlDS を DefaultDS に変更します。
14.3.5.2. より柔軟な方法 リンクのコピーリンクがクリップボードにコピーされました!
DefaultDS に変更することは便利です。 しかし、DefaultDS が常にファクトリデフォルトの HSQL DB を ポイントすることを想定してしまうアプリケーションがある場合、このやり方は アプリケーションを破損する可能性があります。また、DefaultDS 目的地を 変更することは、全ての JBoss サービスが外部データベースを使用することを強制することになります。 その場合、 一部のサービス用のみに外部データベースを使用したい時に問題になるでしょう。
DefaultDS を、 手作業で *-ds.xml ファイル内で定義されたデータソース JNDI 名 (mysql-ds.xml 内の MySqlDS など) に変更します。DefaultDS を含むファイルの完全一覧は次の通りです。 これら全てを更新して全 JBoss サービスで外部データベースを使用するか、 一部を更新してサービスごとに異なる組み合わせのデータソースを使用するようにします。
$JBOSS_HOME/server/PROFILE/conf/login-config.xml: このファイルは Java EE コンテナーで管理するセキュリティサービス内で使用されます。$JBOSS_HOME/server/PROFILE/conf/standardjbosscmp-jdbc.xml: このファイルは EJB コンテナー内で CMP Bean を設定します。$JBOSS_HOME/server/PROFILE/deploy/ejb2-timer-service.xml: このファイルは EJB タイマーサービスを設定します。$JBOSS_HOME/server/PROFILE/deploy/juddi-service.sar/META-INF/jboss-service.xml: このファイルは UUDI サービスを設定します。$JBOSS_HOME/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF/jboss-web.xml: このファイルは UUDI サービスを設定します。$JBOSS_HOME/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF/juddi.properties: このファイルは UUDI サービスを設定します。$JBOSS_HOME/server/PROFILE/deploy/uuid-key-generator.sar/META-INF/jboss-service.xml: このファイルは UUDI サービスを設定します。$JBOSS_HOME/server/PROFILE/deploy/messaging/messaging-jboss-beans.xmlおよび$JBOSS_HOME/server/PROFILE/deploy/messaging/persistence-service.xml: これらのファイルは前述の通り JMS 永続サービスを設定します。
14.3.6. Oracle DataBases に関する注記 リンクのコピーリンクがクリップボードにコピーされました!
schemaname.tablename形式のテーブルを作成します。JBoss Enterprise Application Platform で必要となる TIMERS テーブルと HILOSEQUENCES テーブルが別のスキーマ上に既に存在する場合、 スキーマ上には作成されません。この問題を回避するには、$JBOSS_HOME/server/PROFILE/deploy/ejb2-timer-service.xml ファイルを編集し、 テーブル名を TIMERS から schemaname2.tablename などのように変更します。
$JBOSS_HOME/server/PROFILE/deploy/uuid-key-generator.sar/META-INF/jboss-service.xml ファイルも編集し、テーブル名を HILOSEQUENCES から schemaname2.tablename のように変更します。
重要
SQLException ("Bigger type length than Maximum") を返し問題が発生します。
第15章 DataSource の設定 リンクのコピーリンクがクリップボードにコピーされました!
警告
- トランザクション分離がない
- スレッドおよびソケットがリークする (
connection.close()はリソースの整理を行いません) - 持続品質 (ログは通常、障害後は壊れてしまい自動回復ができなくなります)
- データベースの破損
- 負荷がかけられた際の安定性 (過剰なデータを処理すると、データベース処理は停止されます)
- クラスター化環境では実行不可
15.1. DataSource の種類 リンクのコピーリンクがクリップボードにコピーされました!
DataSource 定義
- <no-tx-datasource>
- JTA トランザクションには関与せず、
java.sql.Driverを使用します。 - <local-tx-datasource>
- 2相コミットには対応しておらず、
java.sql.Driverを使用します。単一データベースあるいは非 XA 対応リソースに適しています。 - <xa-datasource>
- 2 相コミットをサポートせず、
javax.sql.XADataSourceを使用します。
15.2. DataSource パラメーター リンクのコピーリンクがクリップボードにコピーされました!
一般的な DataSource パラメーター
- <mbean>
- 標準的な JBoss MBean デプロイメント
- <depends>
- この
ConnectionFactoryまたはDataSourceデプロイメントが依存する MBean サービスのObjectNameです。 - <jndi-name>
- DataSource がバインドされる JNDI 名です。
- <use-java-context>
- jndi-name のプレフィックスを java: とすべきかを示す Boolean 値です。このプレフィックスは JBoss Enterprise Application Platform の仮想マシン内からしか DataSource にアクセスできなくなります。デフォルトは
trueです。 - <user-name>
- データソースへの接続作成時に使用されるユーザー名です。
注記
セキュリティ設定されている場合は利用されません。 - <password>
- Datasource への接続が作成される際に使用されるパスワードです。
注記
セキュリティ設定されている場合は利用されません。 - <transaction-isolation>
- 接続のデフォルトトランザクション分離です。指定しないとデータベースが提供するデフォルト値が使用されます。
<transaction-isolation> に対し可能な値
- TRANSACTION_READ_UNCOMMITTED
- TRANSACTION_READ_COMMITTED
- TRANSACTION_REPEATABLE_READ
- TRANSACTION_SERIALIZABLE
- TRANSACTION_NONE
- <new-connection-sql>
- 新規接続に対して実行される SQL ステートメントです。接続スキーマの設定などに使用できます。
- <check-valid-connection-sql>
- 有効であるかを確認するため、プールからチェックアウトされる前に実行される SQL ステートメントです。この SQL ステートメントが失敗すると接続が閉じられ、新しい接続が作成されます。
- <valid-connection-checker-class-name>
- ベンダー固有のメカニズムを使用して接続が有効かを確認するクラスです。
- <exception-sorter-class-name>
- ベンダー固有のメッセージを解析し、SQL エラーが致命的でこの接続を破棄するかを判断するクラスです。空の場合、致命的エラーとして処理されるエラーはありません。
- <track-statements>
- 閉じられていない Statement や ResultSet を監視し、閉じられていない場合に警告を発行するかを指定します。デフォルト値は
NOWARNです。 - <prepared-statement-cache-size>
- 後続のリクエストで閉じずに再利用する、接続毎の prepared ステートメントの数です。ステートメントは Least Recently Used (LRU) キャッシュに保存されます。デフォルト値は
0で、これはキャッシュが保持されないということです。 - <share-prepared-statements>
- <prepared-statement-cache-size> が非ゼロの場合、同じトランザクション内の 2 つのリクエストが同じステートメントを返すべきであるかを指定します。デフォルトは
FALSEです。例15.1 <share-prepared-statements>の利用
目的は、ドライバーが自動コミットセマンティックをローカルトランザクションに適応してしまうこのドライバーの動作を回避することです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、prepared ステートメントが同じであることを想定しています。 ドライバーによってはps2.executeQuery()が自動的にrs1を閉じてしまうため、背後に 真の prepared ステートメントが2つ必要となります。 これは、 クエリの再実行が自動的に新しいトランザクションを開始する、 自動コミットセマンテックのみが目的でなければなりません。 仕様に準拠するドライバーの場合、TRUEを設定して同じ真の prepared ステートメントを共有することができます。 - <set-tx-query-timeout>
- トランザクションがタイムアウトするまでの残り時間を基にクエリのタイムアウトを有効にするか指定します。 デフォルトは
FALSEです。 - <query-timeout>
- クエリがタイムアウトするまでの最大時間 (秒)。<set-tx-query-timeout>を
TRUEに設定することでこの値をオーバーライドすることができます。 - <type-mapping>
conf/standardjbosscmp.xml内の型マッピングへのポインターです。この要素は、<metadata> の子要素です。JBoss4 からのレガシー。- <validate-on-match>
- プール外の接続を確認した場合など、JCA 層が管理された接続と一致する場合にこの接続を検証するかどうか指定します。<background-validation>を追加することで、これは必要なくなります。通常、<background-validation> に
TRUEを指定するとともに、<validate-on-match> にTRUEを指定する必要はありません。デフォルト値は、TRUEです。 - <prefill>
- 接続プールに最小接続数を事前に入力を試みるかを指定します。supporting pool (OnePool) のみがこの機能をサポートします。このプールが事前入力に対応しない場合、ログに警告が記録されます。デフォルトは
TRUEとなっています。 - <background-validation>
- バックグラウンドの接続検証は、接続を検証する際の RDBMS システム上の全体的な負荷を軽減します。この機能を使用すると、EAP はプール内の現在の接続が別のスレッド (ConnectionValidator) であるかをチェックします。<background-validation-minutes>は、
TRUEに設定されているこの値により変わります。デフォルトはFALSEです。 - <background-validation-millis>
- バックグラウンドの接続検証は、 接続を検証する際の RDBMS システム上の全体的な負荷を軽減します。 このパラメーターを設定すると、 JBoss はプール内の現在の接続を個別のスレッド(
ConnectionValidator) として検証しようとします。 パラメーターの値がConnectionValidatorの実行周期 (ミリ秒単位) を定義します (この値は<idle-timeout-minutesとは違う値でなければなりません)。 - <idle-timeout-minutes>
- アイドル状態の接続が閉じられるまでの最大時間 (分単位) を示します。値が
0の場合はタイムアウトが無効となります。デフォルトは15です。 - <track-connection-by-tx>
- トランザクションの最後に接続をプールに戻すの代わりに、接続をトランザクションにロックすべきかを指定します。以前のリリースでは、 ローカル接続ファクトリのデフォルト値は
trueで、 XA 接続ファクトリのデフォルト値はfalseでした。現在、 ローカル接続ファクトリと XA 接続ファクトリ両方のデフォルト値がtrueとなり、要素は廃止されました。 - <interleaving>
- XA 接続ファクトリのインターリービングを有効にします。
- <background-validation-minutes>
- ConnectionValidator が実行される頻度 (分単位) になります。デフォルトは
15になります。注記
<min-pool-size> を最小プールサイズセットに指定していない限り、これを、<idle-timeout-minutes>よりも小さい値に設定する必要があります。 - <url-delimiter>, <url-property>, <url-selector-strategy-class-name>
- データベースのフェールオーバーを処理するパラメーター。JBoss Enterprise Application Platform 現在、これらのパラメーターは主なデータソース設定の一部として設定されています。以前のバージョンでは、 <url-delimiter> は <url-delimeter>として表示されていました。
- <stale-connection-checker-class-name>
- 異常な接続を通知する
SQLExceptionがorg.jboss.resource.adapter.jdbc.StateConnectionExceptionの例外をスローするかを決定するorg.jboss.resource.adapter.jdbc.StateConnectionChecker実装です。 - <max-pool-size>
- プール内で接続可能な最大数です。定義されていない場合は、デフォルトは
10となっています。datasource の定義例 ($JBOSS_HOME/server/PROFILE/hsqldb-ds.xml) の値は、20 に設定されています。 - <min-pool-size>
- プールで保持される最小接続数です。<prefill> が
TRUEでない限り、プールが<min-pool-size>まで埋まった時点で最初に利用されるまで、プールは空ままとなります。アイドルによるタイムアウトが原因で、プールサイズが<min-pool-size> 以下に下がった場合、プールは<min-pool-size>まで補充されます。デフォルトは、0となっています。 - <blocking-timeout-millis>
- すべての接続がチェックアウトされた時、接続が使用できるまで待機する時間になります。デフォルトは
30000(30 秒) になります。 - <use-fast-fail>
- 以前の試行が失敗あるいはフェールオーバーが開始された場合でも、プールからの接続取得を試行するかを指定します。これは、SQL 検証の実行に時間とリソースが多くかかるようなパフォーマンスの問題に対処するためです。デフォルトは、
FALSEとなっています。
javax.sql.XADataSource を使用するためのパラメーター
- <connection-url>
- JDBC ドライバー接続の URL ストリングです。
- <driver-class>
java.sql.Driverを実装する JDBC ドライバークラスです。- <connection-property>
java.sql.Driverから取得した接続を設定するために使用されます。例15.2 例:
<connection-property><connection-property name="char.encoding">UTF-8</connection-property>
<connection-property name="char.encoding">UTF-8</connection-property>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
javax.sql.XADataSource を使用するためのパラメーター
- <xa-datasource-class>
XADataSourceを実装するクラスです。- <xa-datasource-property>
XADataSourceの設定に使用されるプロパティです。例15.3 例: <xa-datasource-property> の宣言
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <xa-resource-timeout>
- 0 でない場合、
XAResource.setTransactionTimeout()を経過した秒数になります。 - <isSameRM-override-value>
FALSEに設定した場合、Oracle データベースの問題の一部を修正します。- <no-tx-separate-pools>
- トランザクショナル接続と非トランザクショナル接続を別々にプールします。
警告
このオプションを使うと、実際のプールが2つ作成されるため、合計のプール容量がmax-pool-sizeの2倍になります。Oracle の問題を修正するために利用されます。
セキュリティパラメーター
<application-managed-security>getConnectionに渡されたユーザー名とパスワードを使用するか、 アプリケーションによるcreateConnectionリクエストを使用します。<security-domain>conf/login-module.xmlに設定されている確認されたログインモジュールを使用します。<security-domain-and-application>conf/login-module.xmlに設定されている確認されたログインモジュールや、 アプリケーション (JMS のキューやトピックなど) によって提供される他の接続要求情報を使用します。
JCA レイヤーにてXAをリカバリするためのパラメーター
- <recover-user-name>
- リカバリ操作を行うことのできる認証情報を持つユーザー
- <recover-password>
- リカバリ操作を行うことのできるユーザー (認証情報付き) のパスワード
- <recover-security-domain>
- リカバリ用のセキュリティドメイン
- <no-recover>
- リカバリからのデータソースを除外
15.3. データソースの例 リンクのコピーリンクがクリップボードにコピーされました!
15.3.1. 汎用データソースの例 リンクのコピーリンクがクリップボードにコピーされました!
例15.4 汎用データソースの例
15.3.2. リモート使用向けのDataSource の設定 リンクのコピーリンクがクリップボードにコピーされました!
use-java-context=false を指定します。
例15.5 リモート利用向けの DataSource の設定
java:/GenericDS ではなく GenericDS という JNDI 名でバインドされるため、EAP サーバーと同じ Virtual Machine へのルックアップが制限されます。
注記
15.3.3. ログインモジュールを使用するようDataSource を設定 リンクのコピーリンクがクリップボードにコピーされました!
手順15.1 ログインモジュールを使用するようDataSource を設定
データソースについて、<security-domain-parameter> を XML ファイルに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow login-config.xmlファイルにアプリケーションポリシーを追加します。認証セクションにはログインモジュールの設定が含まれるようにしなければなりません。例えば、 データベースパスワードを暗号化する場合、SecureIdentityLoginModuleログインモジュールを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Web アプリケーションからデータソース接続をフェッチするつもりであれば、Web アプリケーションに対する認証を有効化し、
Subjectが生成されるようにする必要があります。 - ユーザーが無名で接続する機能が必要な場合、 application-policyに別のログインモジュールを追加しセキュリティ証明書を生成します。
UsersRolesLoginModuleモジュールをチェーンの最初に追加します。usersPropertiesとrolesPropertiesパラメーターをダミーファイルに移動することができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第16章 プーリング リンクのコピーリンクがクリップボードにコピーされました!
16.1. 戦略 リンクのコピーリンクがクリップボードにコピーされました!
ManagedConnectionPool を使用してプーリングを実行します。ManagedConnectionPool は、選択された戦略やその他のプーリングパラメーターに応じて、サブプールで構成されます。
|
xml
|
mbean
|
内部名
|
詳細
|
| |
ByNothing
|
OnePool
|
同等の接続の単一プール。
|
|
<application-managed-security/>
|
ByApplication
|
PoolByCRI
|
allocateConnection() より接続プロパティを使用。
|
|
<security-domain/>
|
ByContainer
|
PoolBySubject
|
サブジェクト (事前設定のサブジェクトまたは EJB/Web ログインサブジェクト) 毎のプール。
|
|
<security-domain-and-applicaton/>
|
ByContainerAndApplicaton
|
PoolBySubjectAndCri
|
サブジェクト毎と接続プロパティの組み合わせ。
|
注記
( ConnectionRequestInfo )
(
ConnectionRequestInfo
)
16.2. トランザクションスティッキネス リンクのコピーリンクがクリップボードにコピーされました!
注記
16.3. Oracle での回避法 リンクのコピーリンクがクリップボードにコピーされました!
16.4. プールアクセス リンクのコピーリンクがクリップボードにコピーされました!
16.5. プールの充填 リンクのコピーリンクがクリップボードにコピーされました!
- <min-pool-size/> - 接続数がこの値を下回ると新しい接続が作成されます。
- <max-pool-size/> - この値を越える数の接続は作成されません。
- <prefill/> - 4.0.5 に機能要求が実装されました。 注意: OnePool? または ByNothing? プーリング基準のみがこの機能をサポートします。
重要
16.6. アイドル接続 リンクのコピーリンクがクリップボードにコピーされました!
注記
16.7. 停止接続 リンクのコピーリンクがクリップボードにコピーされました!
connectionErrorOccured() イベントを提供しません。 停止された接続や切断された接続のチェックをサポートするには、 複数のプラグインがあります。
16.7.1. 有効な接続チェック リンクのコピーリンクがクリップボードにコピーされました!
<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>
<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>
<valid-connection-checker-class-name/>
<valid-connection-checker-class-name/>
16.7.2. SQL クエリ中のエラー リンクのコピーリンクがクリップボードにコピーされました!
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
FATAL エラーに関しては、接続が終了します。
16.7.3. プールの変更/終了/フラッシュ リンクのコピーリンクがクリップボードにコピーされました!
- プールの 変更または flush()
- プールを終了するか、アンデプロイすると、 最初にフラッシュされます。
16.7.4. その他プーリング リンクのコピーリンクがクリップボードにコピーされました!
第17章 よくある質問 (FAQ) リンクのコピーリンクがクリップボードにコピーされました!
17.1. Oracle XA の問題 リンクのコピーリンクがクリップボードにコピーされました!
- conf/jboss-service.xml の XidFactory が pad=true になっていますか。
- oracle-xa-ds.xml に <track-connection-by-tx/> がありますか (JBoss Enterprise Application Platform 5.x ではデフォルトで有効におり、 要素が廃止されたため必要ありません)。
- oracle-xa-ds.xml に <isSameRM-override-value>false</isSameRM-override-value> がありますか。
- oracle-xa-ds.xml に <no-tx-separate-pools/> がありますか。
- jbosscmp-jdbc.xml が使用している Oracle と同じバージョンを指定していますか。
- 接続する Oracle サーバーに XA がありますか。
init.oraは \oracle\admin\<your_db_name>\pfileディレクトリにあります。 データベース上で initxa.sql を実行します。 デフォルトでは、 このスクリプトファイルは \oracle\ora81\javavm\install にあります。 ファイル実行中にエラーが発生した場合は、 手作業でファイルから SQL ステートメントを実行する必要があります。 DBA Studio を使用してパッケージと JAVA_XA という名前のパッケージボディーを SYS スキーマに作成し、 このパッケージのシノニム (名前は同様に JAVA_XA) を PUBLIC スキーマに作成します。
パート III. クラスタリングガイド リンクのコピーリンクがクリップボードにコピーされました!
第18章 概要とクイックスタート リンクのコピーリンクがクリップボードにコピーされました!
production サーバープロファイルの一部として、 JBoss Enterprise Application Platform にはそのまま使用できるクラスタリングサポートが含まれています。production サーバープロファイルには次のサポートが含まれています。
- スケーラブルでフォールトトレラントな JNDI 実装 (HA-JNDI)。
- 次を含む Web 層クラスタリング。
- ステートレプリケーションによる Web セッションステートの高可用性。
- ハードウェアロードバランサーやソフトウェアロードバランサーとの統合が可能( mod_jk や JK ベースのソフトウェアロードバランサーとの特殊な統合など)。
- クラスター全体のシングルサインオンサポート。
- ステートフル Bean およびステートレス Bean に対する、EJB3 とEJB2 両方の EJB セッション Bean クラスタリング
- JPA/Hibernate エンティティに対する分散キャッシュ。
- ノード上で Bean に変更があった時にクラスター全体でキャッシュエントリを無効化し、 クラスター全体におけるローカル EJB2 エンティティキャッシュの整合性を維持するフレームワーク。
- 分散 JMS キューと JBoss Messaging によるトピック。
- クラスターの複数のノード上でサービスかアプリケーションをデプロイし、1 つのノード上のみでアクティブにすることを HA シングルトンと呼びます。
Farmサービスにて、デプロイされたコンテンツの同期化をクラスターのすべてのノード上で維持します。
18.1. クイックスタートガイド リンクのコピーリンクがクリップボードにコピーされました!
18.1.1. 最初の準備 リンクのコピーリンクがクリップボードにコピーされました!
- JBoss Enterprise Application Platform をすべてのサーバーにインストールします。 JBoss のダウンロードを各サーバー上のファイルシステムに展開するのが最も簡単な方法です。複数の JBoss Enterprise Application Platform インスタンスを単一のサーバーで実行したい場合は、 完全な JBoss ディストリビューションをファイルシステムの複数の場所にインストールするか、
productionサーバープロファイルのコピーを作成します。例えば、JBoss ディストリビューションのルートが/var/jbossに展開された場合、次を行います。cd /var/jboss/server cp -r production node1 cp -r production node2
$ cd /var/jboss/server $ cp -r production node1 $ cp -r production node2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 各ノードに対して、ソケットをバインドするアドレスを決定します。 クラスター化の有無に関係なく、 JBoss を起動する際に、 ソケットがトラフィックをリッスンするアドレスを JBoss に伝える必要があります (デフォルトは
localhostで、 安全ですがクラスター内ではあまり実用的ではありません)。 そのため、 アドレスを決める必要があります。 - マルチキャストが動作しているか確認します。 デフォルトでは、 JBoss Enterprise Application Platform はほとんどのクラスタ内での通信で UDP マルチキャストを使用します。 各サーバーのネットワーク設定がマルチキャストをサポートし、 サーバー間のスイッチやルーターに対してマルチキャストサポートが有効になっているようにしてください。 1 つのサーバー用で複数のノードを実行したい場合は、 サーバーのルーティングテーブルにマルチキャストルートが含まれているようにしてください。 マルチキャストが動作しているかを確認する JGroups の分析ツールの使用方法など、詳細は http://www.jgroups.org のJGroups ドキュメントを参照してください。
注記
JBoss Enterprise Application Platform のクラスタリングは UDP マルチキャストの使用を必要としません。 クラスター内での通信で TCP ユニキャストを使用するよう再設定することもできます。 - ノード毎に一意の整数 "ServerPeerID" を決定します。 これは JBoss Messaging のクラスタリングに必要で、JBoss Messaging を実行しない場合は必要ありません (サーバープロファイルの
deployディレクトリから JBM を削除する場合など)。JBM を実行する場合、 クラスターの各ノードには"ServerPeerID" と呼ばれる固有の整数 ID が必要になります。重要
簡単な 「1, 2, 3, ..., x」のようなネーミングスキームで構いませんが、値は0から1023の範囲でなければなりません。この範囲外の値になると、ServerPeer 起動サービスで java.lang.IllegalArgumentExceptionが発生します。「JBoss Enterprise Application Platform クラスターの起動」にて、ServerPeerID の使用方法について説明します。
- クラスターに対して固有の名前を選択します。 JBoss Enterprise Application Platform クラスターのデフォルトの名前は 「DefaultPartition」です。 ご自分の環境の各クラスターに対して異なる名前を付けてください (「QAPartition」や「BobsDevPartition」など)。 名前に「Partition」を使用する必要はありませんが、 慣例的に使用されます。 クラスターの周囲で送信されるすべてのメッセージに名前が含まれるため、 パフォーマンスを考慮して短い名前を付けるようにしてください。 選択した名前の使用方法については次の項で取り上げます。
- クラスターに対して固有のマルチキャストアドレスを選択します。 デフォルトでは、 JBoss Enterprise Application Platform はほとんどのクラスタ内の通信に UDP マルチキャストを使用します。 実行する各クラスターに対して異なるマルチキャストアドレスを選択してください。 一般的に、 マルチキャストアドレスには
239.255.x.yの形式を使用するのがよいでしょう。 マルチキャストアドレスの割り当てについては、 http://www.29west.com/docs/THPM/multicast-address-assignment.html を参照してください。 選択したアドレスの使用方法については、 次の項で説明します。
18.1.2. JBoss Enterprise Application Platform クラスターの起動 リンクのコピーリンクがクリップボードにコピーされました!
-c production コマンドラインオプションを使用して同じローカルネットワーク上で複数の JBoss インスタンスを開始することです。これらのサーバーインスタンスは相互に検出を行い、自動的に 1 つのクラスターを形成します。
1、 2 つ目のノードは 2 とします。クラスターの名前を「DocsPartition」とし、 239.255.100.100 をマルチキャストアドレスとして使用するようにします。 シナリオは例の提示を目的としています。例として最も単純であるため 2 ノードのクラスターを使用しますが、 2 ノードがサイズ的に最適であるとは限りません。
- シナリオ 1: 個別のマシン上のノードこのシナリオは実稼働環境では最も一般的なシナリオです。 マシン名は「node1」と「node2」で、 node1 の IP アドレスは
192.168.0.101、 node2 の IP アドレスは192.168.0.102とします。 node1 の ServerPeerID は1、 node2 の ServerPeerID は2とし、 各マシンの/var/jbossに JBoss がインストールされているとします。node1 で JBoss を開始します。cd /var/jboss/bin ./run.sh -c production -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1$ cd /var/jboss/bin $ ./run.sh -c production -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow node2 でも同様ですが、-bの値と ServerPeerID の値が異なります。cd /var/jboss/bin ./run.sh -c production -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2$ cd /var/jboss/bin $ ./run.sh -c production -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2Copy to Clipboard Copied! Toggle word wrap Toggle overflow -cスイッチは、 クラスタリングサポートが含まれるproduction設定の使用を指示します。-gスイッチは、 クラスター名を設定します。-uスイッチはクラスター内での通信で使用されるマルチキャストアドレスを設定します。-bスイッチはソケットがバインドされるアドレスを設定します。-Dスイッチは、 JBoss Messaging が固有の ID を取得するシステムプロパティjboss.messaging.ServerPeerIDを設定します。 - シナリオ 2: 単一のマルチホームサーバー上の 2 ノード同じマシンで複数のノードを実行することは開発環境では一般的で、 実稼働環境でもシナリオ 1 を併用して使用されます (すべてのノードを単一マシン上の実稼働クラスタで実行することは、 マシン自体が単一障害点となるため通常推奨されません)。 このシナリオでは、 マシンがマルチホーム化されています (複数の IP アドレスを持っている状態)。 これにより、 各JBoss インスタンスを異なるアドレスにバインドできるため、 ノードがソケットを開ける際の競合を防ぐことができます。単一のマシンに アドレスとして
192.168.0.101と192.168.0.102が割り当てられ、 シナリオ 1 と同様に 2 つの JBoss インスタンスが同じアドレスと ServerPeerIDs を使用するとします。 シナリオ 1 との違いは、 Enterprise Application Platform インスタンスが独自のワークエリアを持つようにすることです。 そのため、production設定を使用せずに、 前項でproductionよりコピーしたnode1設定とnode2設定を使用するようにします。最初のインスタンスを起動するため、 コンソールウインドウを開いて次を実行します。cd /var/jboss/bin ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1$ cd /var/jboss/bin $ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2 つ目のインスタンスも同様ですが、 -b 値、 -c 値、 ServerPeerID が異なります。cd /var/jboss/bin ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2$ cd /var/jboss/bin $ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.102 -Djboss.messaging.ServerPeerID=2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - シナリオ 3: マルチホーム化されていない単一サーバー上の 2 ノードシナリオ 2 と似ていますが、 マシンの IP アドレスは 1 つのみになります。 2 つのプロセスはソケットと同じアドレスやポートにバインドできないため、 2 つのインスタンスに異なるポートを使用するよう JBoss に伝える必要があります。 これには、
jboss.service.binding.setシステムプロパティを設定して ServiceBindingManager サービスを設定します。最初のインスタンスを起動するため、 コンソールウインドウを開いて次を実行します。cd /var/jboss/bin ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \ -Djboss.service.binding.set=ports-default$ cd /var/jboss/bin $ ./run.sh -c node1 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=1 \ -Djboss.service.binding.set=ports-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 2 つ目のインスタンスには次を実行します。cd /var/jboss/bin ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \ -Djboss.service.binding.set=ports-01$ cd /var/jboss/bin $ ./run.sh -c node2 -g DocsPartition -u 239.255.100.100 \ -b 192.168.0.101 -Djboss.messaging.ServerPeerID=2 \ -Djboss.service.binding.set=ports-01Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、 最初のノード上にある ServiceBindingManager に標準のポートセット (1099 番ポート上の JNDI など) を使用するよう指示します。 2 つ目のノードは、 標準のポート番号から 100 を引いた番号 (1199 番ポート上の JNDI など) を持つ各ポートのデフォルトである ports-01 を使用します。 ServiceBindingManager 設定の全体については、conf/bindingservice.beans/META-INF/bindings-jboss-beans.xmlファイルを参照してください。この設定は異なるポートを使用し、 管理が複雑になるため、 実稼働環境への使用は推奨されません。 クラスタリングを使用したいのにワークステーションをマルチホーム化できない開発環境では一般的なシナリオとなります。注記
技術的に、ports-defaultはデフォルト値であるため、 node1 のコマンドラインに-Djboss.service.binding.set=ports-defaultを含める必要はありませんが、 慣れていないユーザーはすべてのサーバーで統一されたコマンドライン引数を使用した方が簡単でしょう。
18.1.3. Web アプリケーションクラスタリングのクイックスタート リンクのコピーリンクがクリップボードにコピーされました!
HttpSession ステートのバックアップコピーが保存されるクラスタ化された Web セッションをサポートします。 セッションを処理する 1 次ノードに障害が発生あるいは停止した場合、 クラスターの別のノードがバックアップコピーにアクセスし、 セッションの後続要求を処理することができます。Web 層クラスタリングの詳細は 『HTTP コネクター負荷分散ガイド』 を参照してください。
- 外部ロードバランサーの設定。Web アプリケーションは、 JBoss Enterprise Application Platform インスタンスのクラスター全体で HTTP 要求を負荷分散するため、 外部ロードバランサーを必要とします (その理由については、 「外部ロードバランサーアーキテクチャー」 を参照)。 JBoss Enterprise Application Platform 自体は HTTP ロードバランサーとして機能しないため、 ハードウェアロードバランサーかソフトウェアロードバランサーを設定する必要があります。 選択できるロードバランサーは多く存在するため、 ロードバランサーの設定方法については本クイックスタートの範囲外となります。 よく使用される mod_jk ソフトウェアロードバランサーの設定についての詳細は、 『HTTPコネクター負荷分散ガイド』を参照してください。
- クラスタリングに対する Web アプリケーションの設定。 これには、特定の Web アプリケーションに対する希望のクラスタリング動作を JBoss に伝える必要があります。 それには、 空の
distributable要素をアプリケーションのweb.xmlファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記を実行すれば、 ほとんどのアプリケーションでデフォルトの JBoss Enterprise Application Platform のWeb セッションクラスタリング動作を実行できるはずです。詳細設定オプションについては、『HTTP コネクター負荷分散ガイド』を参照してください。
18.1.4. EJB セッション Bean クラスタリングのクイックスタート リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb3.annotation.Clustered アノテーションをステートフル Bean またはステートレス Bean の Bean クラスに追加します。
jboss.xml の Bean のセクションに、 clustered 要素を追加します。
18.1.5. エンティティクラスタリングのクイックスタート リンクのコピーリンクがクリップボードにコピーされました!
persistence.xml を次のように設定します。
org.hibernate.annotations.Cache アノテーションをエンティティクラスに追加します。
注記
第19章 クラスタリングの概念 リンクのコピーリンクがクリップボードにコピーされました!
19.1. クラスター定義 リンクのコピーリンクがクリップボードにコピーされました!
Channel とともに JGroups グループ通信ライブラリによって処理されます。同じ設定と名前を持つ JGroups Channel は動的にお互いのノードを検索し、グループを形成することができます。このため、同じネットワークの 2 つの AS インスタンスで「run -c production」を実行するだけで、ノードがクラスターを形成するようになります。各 Enerprise Application Platform は同じデフォルト設定で Channel (実際には複数) を開始し、その結果、お互いのノードが動的に検索され、クラスターが形成されます。ノードは、他のクラスターメンバーと同じ設定と名前で Channel を開始または停止するだけでいつでもクラスターに動的に追加、あるいはクラスターから動的に削除できます。
Channel を作成することができます。Enterprise Application Platform 5 の production サーバープロファイルを標準起動すると、 2 つの異なるサービスが合計 4 つのチャネルを作成します。JBoss Messaging が 2 つのチャネルを作成し、 HAPartition と呼ばれるコアの汎用クラスタリングサービスも 2 つのチャネルを作成します。 クラスター化された Web アプリケーションやクラスター化された EJB3 SFSB、クラスター化された JPA/Hibernate エンティティキャッシュをデプロイすると、追加のチャネルが作成されます。 Enterprise Application Platform が接続するチャネルは、大きく 3 つに分類されます (HAPartition サービスが使用する汎用チャネル、特別用途のキャッシングやクラスター全体のステートレプリケーション向けに JBoss Cache が作成したチャネル、 JBoss Messaging が使用する 2 つのチャネル)。
run -c production を実行すると、お互いのチャネルが検索され、概念的な cluster が形成されます。これは 2 ノードクラスターと考えると分かりやすいですが、実際には 4 つのチャネル、したがって 4 つの 2 ノードクラスターであると理解することが重要です。
-g (パーティション名) と -u (マルチキャストアドレス) 起動スイッチに渡すことだけが必要になります。 各サーバーセットには異なる値を選択する必要があります。「JGroups 設定」と「JGroups チャネルの分離」の項に、 検索したいピアのみを見つけるようEnterprise Application Platform を設定する方法が説明されています。
図19.1 クラスターとサーバーノード
19.2. サービスアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
19.2.1. クライアント側インターセプターアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
図19.2 クラスタリング用クライアント側インターセプター (プロキシ) アーキテクチャー
19.2.2. 外部ロードバランサーアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
図19.3 クラスタリング用外部ロードバランサーアーキテクチャー
19.3. 負荷分散ポリシー リンクのコピーリンクがクリップボードにコピーされました!
19.3.1. クライアント側インターセプターアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
- Round-Robin: 各呼び出しは、 ノードの一覧の順に新しいノードへ配信されます。 最初のターゲットノードは一覧より無作為に選択されます。
org.jboss.ha.framework.interfaces.RoundRobin(レガシー) とorg.jboss.ha.client.loadbalance.RoundRobin(EJB3) によって実装されます。 - Random-Robin: 各呼び出しに対して一覧よりターゲットノードを無作為に選択します。
org.jboss.ha.framework.interfaces.RandomRobin(レガシー) とorg.jboss.ha.client.loadbalance.RandomRobin(EJB3) によって実装されます。 - First Available: 使用可能なターゲットノードの 1 つがメインターゲットとして選択されてから全てのコールに使用されます。 選択されるメンバーはクラスター内のメンバーの一覧から無作為に選択されます。 ターゲットノードの一覧が変更されると (1 ノードが起動または停止したため)、 現在選択されているノードが使用可能である場合を除き、 ポリシーによって新しいターゲットノードが選択されます。 各クライアント側プロキシは、他のプロキシに関係なく独自のターゲットノードを選択します。 そのため、 特定のクライアントが同じターゲットサービス (EJB など) に対して 2 つのプロキシをダウンロードする場合、各プロキシは独立してターゲットを選択します。 これが「セッションアフィニティ」または「スティッキーセッション」を提供するポリシーの例となります (ターゲットノードは確立されると変更されないため)。
org.jboss.ha.framework.interfaces.FirstAvailable(レガシー) やorg.jboss.ha.client.loadbalance.aop.FirstAvailable(EJB3) によって実装されます。 - First Available Identical All Proxies: 「First Available」 ポリシーと同じ動作になりますが、 選択されるターゲットノードは同じターゲットサービスに関連付けられた同じクライアント側 VM のすべてのプロキシで共有されます。 そのため、 特定のクライアントが同じターゲットサービス (EJB など) に対して 2 つのプロキシをダウンロードする場合、 各プロキシは同じターゲットを使用します。
org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies(レガシー) やorg.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies(EJB3) によって実装されます。
org.jboss.ha.framework.interfaces.LoadBalancePolicy インターフェースを実装します。ユーザーは特殊な動作を必要とする場合にこの単純なインターフェースの独自の実装を自由に作成できます。後半のセクションでは、さまざまなサービスによって使用される負荷分散ポリシーの設定方法について説明します。
19.3.2. 外部ロードバランサーアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
- Transaction-Sticky Round-Robin: Round-Robin のトランザクションスティッキー変異です。
org.jboss.ha.framework.interfaces.TransactionStickyRoundRobinによって実装されます。 - Transaction-Sticky Random-Robin: Random-Robin のトランザクションスティッキー変異です。
org.jboss.ha.framework.interfaces.TransactionStickyRandomRobinによって実装されます。 - Transaction-Sticky First Available: First Available のトランザクションスティッキー変異のです。
org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailableによって実装されます。 - Transaction-Sticky First Available Identical All Proxies: First Available Identical All Proxies のトランザクションスティッキー変異です。
org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailableIdenticalAllProxiesによって実装されます。
第20章 ビルディングブロックのクラスター化 リンクのコピーリンクがクリップボードにコピーされました!
図20.1 JBoss Enterprise Application Platform のクラスタリングアーキテクチャー
20.1. JGroups とのグループ通信 リンクのコピーリンクがクリップボードにコピーされました!
Channel を取得し、 通信するために使用します。 Channel は、どのノードがグループのメンバーであるかを管理し、 ノードの障害を検出して、 すべてのグループメンバに対してメッセージを失わないよう先着 (FIFO) 順にメッセージを発信します。 また、フロー制御を提供し、低速のメッセージ受信者が高速のメッセージ送信者によって圧倒されないようにします。
Channel の特徴は、 JGroups Channel を構成するプロトコルのセットによって決まります。 各プロトコルはグループ通信タスク全体の 1 つのアスペクトを処理します。 例えば、 UDP プロトコルは UDP データグラムの送受信の詳細に対応します。 UDP プロトコルを使用する Channel は UDP ユニキャストとマルチキャストと通信することができます。 TCP プロトコルを使用する Channel は、 すべてのメッセージに対して TCP ユニキャストを使用することができます。 JGroups は多くのプロトコルをサポートしていますが (詳細は 「JGroups チャネルのプロトコルスタックを設定」 を参照)、 Enterprise Application Platform には多くのニーズに対応するチャネル設定のデフォルトセットが同梱されています。
$JBOSS_HOME/bin/でrun.confを作成し、そのファイルを開きJAVA_OPTS="$JAVA_OPTS -Djboss.default.jgroups.stack=<METHOD>"を追加します。
20.1.1. チャネルファクトリサービス リンクのコピーリンクがクリップボードにコピーされました!
Channel インスタンスのファクトリとして、 新しい ChannelFactory サービスが使用されるようになりました。 チャネルが必要なサービスは ChannelFactory よりチャネルをリクエストし、 希望する設定の名前を渡します。
server/production/deploy/cluster/jgroups-channelfactory.sar にデプロイされます。 ChannelFactory サービスは起動時に名前 (UDP や TCP など) によって識別される様々な標準 JGroups 設定が含まれる server/production/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml ファイルを構文解析します。チャネルが必要なサービスはチャネルファクトリにアクセスし、特定の名前付き設定を持つチャネルを要求します。
注記
cluster_name 引数を Channel.connect(String cluster_name) メソッドに渡します。 ネットワーク上で受信したメッセージが意図されたものであるかを判断する要素の 1 つとして、 チャネルは cluster_name を使用します。
20.1.1.1. 標準のプロトコルスタック設定 リンクのコピーリンクがクリップボードにコピーされました!
udp、jbm-control、 jbm-data になります。JBoss Messaging 以外のクラスタリングサービスは udp を使用します。
stack 要素を server/production/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml ファイルに追加します。 このファイルを編集すると、既存設定の動作を変更できます。 追加や変更を行う前に、 Enterprise Application Platform に同梱される標準設定を確認してみてください。 ニーズに合った標準設定があるかもしれません。 また、 設定を編集する前にどのサービスがこの設定を利用しているか把握し、影響を受ける全サービスに対して、変更したい設定が適切であるよう確認します。特定のサービスに対して変更が不適切な場合、 新しい設定を作成して一部のサービスが新しい設定を使用するよう変更した方がよいかもしれません。
- udpUDP マルチキャストベースのスタックは、 異なるチャンネルによって共有されることを目的としています。 同期グループ RPC の待ち時間が長くなるため、 メッセージのバンドルは無効になっています。 非同期 RPC のみを大量に呼び出すサービス (REPL_ASYNC 向けに設定された JBoss Cache など) の場合、 次のようにキャッシュが
udp-asyncスタックを使用するよう設定するとパフォーマンスを改善できるでしょう。 同期 RPC のみを呼び出すサービス (REPL_SYNC や INVALIDATION_SYNC 向けに設定された JBoss Cache など) の場合、 フロー制御が含まれない次のudp-syncスタックを使用するとパフォーマンスを改善できるでしょう。 - udp-async前述のデフォルトの
udpスタックと同じですが、 トランスポートプロトコルでメッセージバンドルが有効になっています (enable_bundling=true)。 メッセージのバインドによりパフォーマンスが改善できる大量の非同期 RPC (REPL_ASYNC 向けに設定された大量の JBoss Cache インスタンスなど) を呼び出すサービスに対して有用です。 - udp-syncフロー制御やメッセージバンドルがない UDP マルチキャストベースのスタックです。 同期呼び出しが使用され、 メッセージの量 (メッセージ比率とサイズ) が大きくない場合、
udpの代わりに使用することができます。持続率が高い状態でメッセージを送信する場合、 メモリが不足することがあるため、 この設定は使用しないでください。 - tcpフロー制御とメッセージバンドルを持つ TCP ベースのスタックです。TCP スタックは通常、 ネットワークで IP マルチキャストが使用できない場合に使用します (ルーターがマルチキャストを破棄する場合など)。
- tcp-syncフロー制御やメッセージバインドがない TCP ベースのスタックです。 TCP スタックは通常、 ネットワークで IP マルチキャストが使用できない場合に使用します (ルーターがマルチキャストを破棄する場合など)。 同期呼び出しが使用され、 メッセージの量 (メッセージ比率とサイズ) が大きくない場合、 前述の
tcpの代わりにこの設定を使用するようにしてください。高い持続率でメッセージを送信する場合、 メモリが不足することがあるため、 この設定は使用しないでください。 - jbm-controlJBoss Messaging の制御チャネル向けに最適化されたスタックです。 デフォルトでは、 前述の
udpスタックがデフォルトで使用する UDP トランスポートプロトコル設定と同じ設定が使用されます。 これにより、 JBoss Messaging の制御チャネルが、 他の標準 JBoss Enterprise Application Platform のクラスタされたサービスが使用するソケットやネットワークバッファー、 スレッドプールを使用できるようになります (「JGroups 共有トランスポート」 を参照してください)。 - jbm-dataJBoss Messaging データチャネル向けに最適化された TCP ベースのスタックです。
20.1.1.2. プロトコルスタック設定の変更 リンクのコピーリンクがクリップボードにコピーされました!
udp プロトコルスタック設定を利用します。TCPベースの設定を利用したい場合、system property jboss.default.jgroups.stackをtcp の値(-Djboss.default.jgroups.stack=tcp)に設定してください。この変更により、JGroups チャネルを使うサービスのほとんどをTCPベースの設定に構成します。tcp をデフォルトのプロトコルスタックにするには、Linux プラットフォームでは $JBOSS_HOME/bin/run.confにあるJAVA_OPTS の環境変数に、またWindows プラットフォームでは$JBOSS_HOME/bin/run.conf.batにある環境変数をこのシステムプロパティを追加します。
tcp スタックは、ピア検出に (MPING層経由で) UDPマルチキャストを使います。こうすることで、スタックが環境固有のホスト設定を避け、カスタマイズなしに使うことができます。UDPマルチキャストを利用できない場合、非UDPベースのピア検出層 (TCPPING層)に変更し、必要と考えられるクラスターノードのアドレス/ポートを設定する必要があります。jgroups-channelfactory-stacks.xml からプロトコルスタック設定を変更できます。このファイルには、両ピア検出層の定義をを含みます。デフォルトでは、MPING層の定義はアンコメントされ、TCPPING層はコメントされています。非UDPベースのピア検出に切り替えるには、MPING層をコメント、TCPPING層をアンコメントし、設定します。MPINGおよびTCPPINGの詳細情報は、「ディスカバリプロトコル」 を参照してください。
20.1.1.3. JBoss Messagingのプロトコルスタック設定 リンクのコピーリンクがクリップボードにコピーされました!
jbm-control および jbm-data プロトコルスタック設定を利用します。jbm-control プロトコルスタックは、完全にUDPベースとなっており、jbm-data はUDPマルチキャストを採用するMPING検出プロトコルを使います。そのため、JBoss Messaging でTCPベースの設定のみを使いたい場合は、JBoss Messaging コントロールチャネルをjbm-control スタックの代わりにtcp プロトコルスタックを使用するよう設定し、jbm-data プロトコルスタックがMPING層の代わりにTCPPING層を利用するように変更しなければなりません。
tcp プロトコルスタックを使うように設定するには、deploy/messaging/RDMS-persistence-service.xmlファイルを開き(RDMS の値はメッセージの永続化に利用している関係データベース管理システムにより変わります)、org.jboss.messaging.core.jmx.MessagingPostOfficeService mbeanのControlChannelName 属性値をtcpに変更します。
<!--<attribute name="ControlChannelName">jbm-control</attribute>--> <attribute name="ControlChannelName">tcp</attribute>
<!--<attribute name="ControlChannelName">jbm-control</attribute>-->
<attribute name="ControlChannelName">tcp</attribute>
/server/PROFILE/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml を開き、例20.1「TCPPING 定義を持つjbm-data プロトコルスタックの定義」に示されているようにMPING層を同等のTCPPING層に置き換えます。
例20.1 TCPPING 定義を持つjbm-data プロトコルスタックの定義
20.2. JBoss Cache による分散キャッシング リンクのコピーリンクがクリップボードにコピーされました!
- クラスター化された Web アプリケーションセッションのレプリケーション
- クラスター化された EJB3 ステートフルセッション Bean のレプリケーション
- JPA および Hibernate エンティティのクラスター化されたキャッシング
- クラスター化されたシングルサインオン
- HA-JNDI レプリケートツリー
- DistributedStateService
20.2.1. JBoss Enterprise Application Platform の CacheManager サービス リンクのコピーリンクがクリップボードにコピーされました!
deploy/ ディレクトリへデプロイされたため、 次のような欠点がありました。
- エンドユーザーが必要ないキャッシュもデプロイされ、 各キャッシュが JGroup チャネルを作成しました。 例えば、 クラスター化された EJB3 SFSB がなくても、 保存されるキャッシュが開始されました。
- キャッシュはキャッシュを使用するサービスの内部的な詳細であるため、 ファーストクラスのデプロイメントとするべきではありません。
- サービスは JMX ルックアップよりキャッシュを検索するのですが、管理インターフェースを公開する目的以外で JMX を使用することは、JBoss Enterprise Application Platform 5 の方針に反します。
$JBOSS_HOME/server/production/deploy/cluster/jboss-cache-manager.sar よりデプロイされる新しい CacheManager サービスに置き換えられました。 CacheManager はファクトリで、JBoss Cache インスタンスのレジストリです。 キャッシュが必要なサービスは、 名前を用いてキャッシュマネージャーにキャッシュを要求します。 キャッシュマネージャがキャッシュを作成し (キャッシュが作成されていなかった場合)、返します。キャッシュマネージャーは作成したキャッシュの参照を保持するため、 同じキャッシュ設定名をリクエストするすべてのサービスが同じキャッシュを共有します。 サービスは使用を終えたキャッシュをキャッシュマネージャーに解放します。 キャッシュマネージャは各キャッシュを使用するサービスの数を把握し、すべてのサービスがキャッシュを解放した後にキャッシュを停止し破棄します。
20.2.1.1. 標準のキャッシュ設定 リンクのコピーリンクがクリップボードにコピーされました!
deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml ファイルを編集します (詳細は 「CacheManager サービスによるデプロイメント」 を参照)。 ただし、 これらの設定は使用目的に合わせて最適化されているため、 本ガイドの各サービスに対する章に明確に説明がない限り、 変更しない方がよいでしょう。
- standard-session-cacheWeb セッションに使用される標準のキャッシュです。
- field-granularity-session-cacheFIELD 粒度の Web セッションに使用される標準のキャッシュです。
- sfsb-cacheEJB3 SFSB キャッシングに使用される標準のキャッシュです。
- ha-partitionWeb の階層のクラスター化されたシングルサインオン、 HA-JNDI、 分散ステートによって使用されます。
- mvcc-entityJBoss Cache の MVCC ロッキングを使用する JPA/Hibernate エンティティ/コレクションキャッシングに適切な設定です (下記の注記を参照)。
- optimistic-entityJBoss Cache の楽観的ロッキングを使用する JPA/Hibernate のエンティティ/コレクションキャッシングに適切な設定です (下記の注記を参照)。
- pessimistic-entityJBoss Cache の悲観的ロッキングを使用する JPA/Hibernate のエンティティ/コレクションキャッシングに適切な設定です (下記の注記を参照)。
- mvcc-entity-repeatable「mvcc-entity」と同じですが、READ_COMMITTED ではなく JBoss Cache の REPEATABLE_READ 分離レベルを使用します (下記の注記を参照)。
- pessimistic-entity-repeatable「pessimistic-entity」と同じですが、READ_COMMITTED ではなく JBoss Cache の REPEATABLE_READ 分離レベルを使用します (下記の注記を参照)。
- local-queryJPA/Hibernate のクエリ結果のキャッシングに適切な設定です。 クエリの結果はレプリケートしません。 このキャッシュのクエリ結果が有効であるかを検証するために Hibernate が使用するタイムスタンプデータを保存しないでください。
- replicated-queryJPA/Hibernate のクエリ結果のキャッシングに適切な設定です。 クエリの結果をレプリケートします。 このキャッシュのクエリ結果が有効であるかを検証するために Hibernate が使用するタイムスタンプデータを保存しないでください。
- timestamps-cacheJPA/Hibernate のクエリ結果キャッシングの一部としてキャッシュされるタイムスタンプデータに適切な設定です。 クエリ結果自体が
local-queryのような非リプリケーションキャッシュを使用する場合でも、 クエリ結果キャッシングが使用される時はレプリケートされたタイムスタンプのキャッシュが必要となります。 - mvcc-sharedJPA/Hibernate のエンティティ、コレクション、クエリ結果、タイムスタンプキャッシングで共有されるキャッシュに適切な設定です。最も非効率なモードである REPL_SYNC キャッシュモードが必要となるため、推奨される設定ではありません。 また、 起動時にフルステート転送が必要となるため、高価になることがあります。JBoss 4 では共有キャッシュのみが使用できたため、後方互換性を理由に維持されています。JBoss Cache の MVCC ロックを使用します。
- optimistic-sharedJPA/Hibernate のエンティティ、コレクション、クエリ結果、タイムスタンプキャッシングで共有されるキャッシュに適切な設定です。最も非効率なモードである REPL_SYNC キャッシュモードが必要となるため、推奨される設定ではありません。 また、起動時にフルステート転送が必要となるため、高価になることがあります。 JBoss 4 では共有キャッシュのみが使用できたため、後方互換性を理由に維持されています。JBoss Cache の 楽観的ロックを使用します。
- pessimistic-sharedJPA/Hibernate のエンティティ、 コレクション、 クエリ結果、 タイムスタンプキャッシングで共有されるキャッシュに適切な設定です。 最も非効率なモードである REPL_SYNC キャッシュモードが必要となるため、 推奨される設定ではありません。 また、 起動時にフルステート転送が必要となるため、高価になることがあります。 JBoss 4 では共有キャッシュのみが使用できたため、後方互換性を理由に維持されています。JBoss Cache の悲観的ロックを使用します。
- mvcc-shared-repeatable「mvcc-shared」と同じですが、READ_COMMITTED ではなく JBoss Cache の REPEATABLE_READ 分離レベルを使用します (下記の注記を参照)。
- pessimistic-shared-repeatable「pessimistic-shared」と同じですが、 READ_COMMITTED ではなく JBoss Cache の REPEATABLE_READ 分離レベルを使用します (下記の注記を参照)。
注記
注記
20.2.1.2. キャッシュ設定エイリアス リンクのコピーリンクがクリップボードにコピーされました!
jboss-cache-manager-jboss-beans.xml ファイルの 「CacheManager Bean」 を編集して設定することができます。 次の設定は、 Enterprise Application Platform 5 の標準的なエイリアスになります。
20.3. HAPartition サービス リンクのコピーリンクがクリップボードにコピーされました!
Channel の上部に構築された抽象層です。 HAPartition を使用するサービスは単一の Channel や多重 RPC 呼び出しを共有できるため、設定を簡易化することができ、各サービスが独自の Channel を作成するランタイムオーバーヘッドが発生しなくなります。 また、HAPartition はどのクラスタリングサービスがどのクラスタメンバで実行されているかを記録する分散レジストリもサポートし、クラスタメンバーシップやクラスター化されたサービスレジストリが変更されたときに該当するリスナに通知します。さらに、HAPartition は、スマートなクライアントサイドクラスタプロキシ、EJB 2 SFSB レプリケーションおよびエンティティキャッシュ管理、ファーミング、HA-JNDI、HA シングルトンなどの、本書でこれから説明する多くの重要なクラスタリングサービスを形成します。
HAPartition サービスの定義を表しています。 この設定は、 server/production/deploy/cluster/hapartition-jboss-beans.xml ファイルにあります。
HAPartitionCacheHandler と HAPartition の 2 つの Bean が定義されています。
HAPartition Bean は次の設定プロパティを公開します。
- PartitionName はクラスター名を指定する任意の属性です。 デフォルト値は
DefaultPartitionです。-g(または --partition) コマンドラインスイッチを使用して、 サーバー起動時にこの値を設定します。注記
MCBean:ServerConfig プロファイルサービスコンポーネントにあるpartitionName を使う場合、システムは当プロパティに対して null 値を返します。MCBean:HAPartition 管理のコンポーネントからのPartionName を使い正しい値を取得します。 - nodeAddress は未使用のため、 無視しても問題ありません。
- stateTransferTimeout は初期のアプリケーションステート転送のタイムアウト値 (ミリ秒単位) を指定します。 ステート転送は、 サービスの起動時にすでに実行されているクラスタメンバから初期のアプリケーションステートのシリアライズされたコピーを取得するプロセスを意味します。 デフォルト値は
30000です。 - methodCallTimeout は、 別のクラスターメンバーからグループ RPC への応答を取得する時のタイムアウト値( ミリ秒単位) を指定します。 デフォルト値は
60000です。
HAPartitionCacheHandler は HAPartition とJBoss Cache の統合を手助けする小さなユーティリティサービスです (「JBoss Enterprise Application Platform の CacheManager サービス」 を参照)。 HAPartition はJBoss Cache を使用する DistributedState と呼ばれる子サービスを公開します (「DistributedState サービス」参照)。 HAPartitionCacheHandler は、 DistributedState のキャッシュが使用する JGroups Channel と HAPartition が直接使用する Channel 間の設定が一貫性を保つようにします。
- cacheConfigName は、 HAPartition 関連のキャッシュに使用する JBoss Cache 設定の名前になります。 HAPartition が使用するべきである JGroups プロトコルスタック設定の名前も間接的に指定します。 JGroups プロトコルスタックの設定方法は、 「JGroups の統合」 を参照してください。
PartitionName が同じでなければなりません。 また、 HAPartitionCacheHandler の cacheConfigName が同じ JBoss Cache 設定を指定しなければなりません。 どちらかの要素を一部のノードで変更すると、クラスターが適切に動作しなくなります。
http://hostname:8080/jmx-console/ など) にアクセスしてから jboss:service=HAPartition,partition=DefaultPartition MBean (-g 起動スイッチを使用する場合はご使用のパーティション名が反映されるよう MBean 名を変更) をクリックすると現在のクラスタ情報を表示することができます。 現在のクラスターメンバーの IP アドレス一覧は CurrentView フィールドに表示されます。
注記
20.3.1. DistributedReplicantManager サービス リンクのコピーリンクがクリップボードにコピーされました!
DistributedReplicantManager (DRM) サービスは、 HAPartition.getDistributedReplicantManager() メソッドにより HAPartition ユーザーが使用できる HAPartition サービスのコンポーネントの 1 つです。 通常、 JBoss Enterprise Application Platform のユーザーは直接 DRM を利用することはありません。 ここでは、 Enterprise Application Platform のクラスタリング内部がどのように動作するかを詳しく知りたいユーザー向けに説明します。
- クラスター化されたスマートプロキシクラスター化された EJB の名前など、クラスター化されたスマートプロキシを必要とするサービスの名前がキーとなります (「クライアント側インターセプターアーキテクチャー」 を参照)。 各ノードが DRM に保存する値オブジェクトは「ターゲット」と呼ばれます。 スマートプロキシのトランスポート層はこのターゲットを使用してノードへコンタクトします (RMI スタブ、 HTTP URL、 JBoss Remoting の
InvokerLocatorなど)。 クラスター化されたスマートプロキシを構築するファクトリが DRM にアクセスして、プロキシに挿入するべきである「ターゲット」のセットを取得し、クラスター内のすべてのノードと通信できるようにします。 - HASingleton高可用シングルトンとして機能する必要があるサービスの名前がキーとなります (HASingleton の章を参照)。 各ノードが DRM に保存する値オブジェクトは、 トークンとして動作するストリングで、 ノードにサービスがデプロイされていることを示します。 そのため、 HA シングルトンサービスの「マスター」ノードの候補になります。
20.3.2. DistributedState サービス リンクのコピーリンクがクリップボードにコピーされました!
DistributedState サービスは、 HAPartition.getDistributedState() メソッドによって HAPartition ユーザーが利用できる HAPartition サービスのレガシーコンポーネントです。 このサービスはクラスターの周囲に任意アプリケーションステートの連携管理を提供します。 このサービスは後方互換性を維持するためにサポートされていますが、 新しいアプリケーションではこのサービスを使用せず、 より高度な JBoss Cache を代わりに使用してください。
DistributedState サービスは基礎の JBoss Cache インスタンスへ委譲します。
20.3.3. HAPartition のカスタム使用 リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ha.framework.server.HAServiceImpl ベースクラスを拡張するのが一番簡単な方法です。 JMX の登録や通知のサポートが必要な場合は org.jboss.ha.jxm.HAServiceMBeanSupport クラスを拡張します。
第21章 クラスター化 JNDI サービス リンクのコピーリンクがクリップボードにコピーされました!
- ネーミング処理の透過的なフェイルオーバー。 HA-JNDI ネーミングコンテキストは特定の JBoss Enterprise Application Platform インスタンス上の HA-JNDI サービスに接続され、 サービスは失敗するか、 シャットダウンされます。 HA-JNDI クライアントは別の Enterprise Application Platform インスタンスに透過的にフェイルオーバーできます。
- ネーミング処理の負荷分散。 HA-JNDI ネーミングコンテキストはクラスター内のすべての HA-JNDI サーバーで要求を自動的に負荷分散します。
- HA-JNDI サーバーの自動クライアント検出 (マルチキャストを使用)
- クラスター全体の JNDI ツリーの統合ビュー。 クライアントはクラスター内の任意のノードで実行されている HA-JNDI サービスに接続し、 他のノードの JNDI でバインドされたオブジェクトを検索できます。 これは以下の 2 つのメカニズムによって実現されます。
- クラスター間ルックアップ。 クライアントはルックアップを実行でき、 サーバー側 HA-JNDI サービスはクラスタ内のノードにある通常の JNDI でバインドされたものを検索できます。
- 複製されたクラスター全体のコンテキストツリー。 HA-JNDI サービスにバインドされたオブジェクトは、 クラスター全体で複製され、 そのオブジェクトのコピーはクラスターの各ノードの VM で利用できます。
- EJB がクラスター対象として設定されていない場合は、 HA-JNDI を使用して EJB をルックアップしても、EJB にクラスタリング機能 (EJB 読み出しの負荷分散、 透過的なフェイルオーバー、 状態レプリケーション) が追加されません。
- EJB がクラスター対象として設定された場合は、 HA-JNDI の代わりに通常の JNDI を使用して EJB をルックアップしても、 Bean プロキシのクラスタリング機能は削除されません。
21.1. 仕組み リンクのコピーリンクがクリップボードにコピーされました!
InitialContext オブジェクトより)、 プロキシよりリモートサーバーの JNDI ルックアップサービスを呼び出します。 クライアントは InitialContext オブジェクトによって使用されるネーミングプロパティを設定し、 HA-JNDI プロキシを要求します。 この詳細は 「クライアントの設定」 で取り上げています。 InitialContext に適切なネーミングプロパティが提供されていることを確認する必要がある以外は、 ネーミングコンテキストが HA-JNDI を使用していることはクライアントに対して透過的です。
- すでに JNDI 実装がローカルであることを前提としていたので、アプリケーションに伴う移行関連の問題を回避し、設定ファイルを少し調整するだけでそのまますぐクラスタリングを機能するようにしたかったこと。
- 同種のクラスターでは、 この構成によってネットワークトラフィック量が軽減され、同じタイプのオブジェクトが各ノードの同じ名前にバインドされること。
- このような設計により、 基礎となるすべてのクラスターコードが新しい
InitialContextを使用してバインディングをルックアップしたり作成するため、 HA-JNDI サービスは任意のサービスとなります。
new InitialContext() の呼び出しによって取得されたネーミングコンテキストがローカル専用のクラスタワイドでない JNDI コンテキストにバインドされます。 このため、 すべての EJB ホームなどはクラスター全体の JNDI コンテキストにはバインドされませんが、各ホームはローカルの JNDI にバインドされます。
- クラスタ全体の JNDI ツリーにバインディングがある場合はそれを返します。
- クラスター全体のツリーにバインディングがない場合、 ルックアップのクエリをローカルの JNDI サービスに委任して受信した応答があればそれを返信します。
- 応答を受信しなかった場合、 HA-JNDI サービスはクラスター内の他すべてのノードに対しローカルの JNDI サービスがそのようなバインディングを持っているか問い合わせ、 受信するセットからの応答を返します。
- バインディングを持つローカルの JNDI サービスがない場合、 最終的には
NameNotFoundExceptionが発行されます。
注記
注記
注記
ExternalContext MBean を用いる JNDI フェデレーションを使用すると、 非 JBoss INDI ツリーを JBoss JNDI の名前空間へバインドすることができます。 また、 クラスター全体やHA-JNDI やJNP のスクラップに 1 つの集中 JNDI サーバーを使用することもできます。
21.2. クライアントの設定 リンクのコピーリンクがクリップボードにコピーされました!
InitialContext が作成された時に適切なネーミングプロパティ環境が使用できるようにします。 この方法は、 クライアントが JBoss Enterprise Application Platform 内で実行されているか別の VM で実行されているかによって異なります。
21.2.1. Enterprise Application Platform 内部で実行されているクライアントの場合 リンクのコピーリンクがクリップボードにコピーされました!
InitialContext を設定する必要があります。 次のコードは HA-JNDI にバインドされたネーミングコンテキストの作成方法について示しています。
deploy/cluster/hajndi-jboss-beans.xml ファイルに設定された HA-JNDI サービスを示しています (「JBoss の設定」 を参照)。 デフォルトでは、 このサービスは jboss.bind.address システムプロパティより命名されたインターフェースをリッスンします。 jboss.bind.address システムプロパティは、 JBoss Enterprise Application Platform 起動時に -b コマンドラインオプションへ割り当てた値に設定されます (指定がない場合は localhost)。 上記のコードはこのプロパティへのアクセス例になります。
jnp.partitionName プロパティを指定して InitialContext が VM 内の HA-JNDI を静的に見つけるようにするのが最も安全なやり方です。
jboss.partition.name システムプロパティを使用して、 HA-JNDI サービスが動作するパーティションを特定します。 このシステムプロパティは、 JBoss Enterprise Application Platform 起動時に -g コマンドラインオプションへ割り当てた値に設定されます (指定がない場合は DefaultPartition)。
jndi.properties ファイルをデプロイメントに配置し、Enterprise Application Platform の conf/jndi.properties ファイルを編集して作業を単純化しないようにしてください。 いずれの場合でもほぼ間違いなくアプリケーションが破損し、場合によってはサーバー全体が破損します。 クライアント設定を外部化するには、 jndi.properties という名前でないプロパティファイルをデプロイし、 そのファイルの内容をロードする Properties オブジェクトをプログラムを使用して作成するのが 1 つの方法です。
21.2.1.1. EJB および WAR からのHA-JNDI リソースへのアクセス -- 環境ネーミングコンテキスト リンクのコピーリンクがクリップボードにコピーされました!
${jboss.bind.address} 構文は、 URL を判定する時に jboss.bind.address システムプロパティの値を使用するよう JBoss に伝えます。 このシステムプロパティは、 JBoss Enterprise Application Platform の起動時に -b コマンドラインオプションで割り当てた値をシステムプロパティ自体に設定します。
21.2.1.2. 単に jndi.properties ファイルに指定するのではなく、 プログラムを使用して行う理由 リンクのコピーリンクがクリップボードにコピーされました!
conf/jndi.properties ファイルによって制御されます。
21.2.1.3. 正しくない HA-JNDI へバインドされたことを知る方法 リンクのコピーリンクがクリップボードにコピーされました!
jboss:service=JNDIView MBean 上で list 操作を実行します。結果の最後の方に「HA-JNDI Namespace」の内容が一覧表示されます。 通常、一覧には何も表示されませんが、 明示的にバインドしなかったデプロイメントが表示された場合、 不適切な jndi.properties ファイルがクラスパスにあると考えられられます。例は、Problem with removing a Node from Cluster を参照してください。
21.2.2. Enterprise Application Platform 外部で実行されているクライアントの場合 リンクのコピーリンクがクリップボードにコピーされました!
jndi.properties ファイル内の java.naming.provider.url JNDI 設定に渡すことができます。 各サーバーノードは IP アドレスと JNDI ポート番号によって識別されます。 サーバーノードはコンマで区切ります (サーバーとポートの設定方法については 「JBoss の設定」 を参照)。
java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100
java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100
注記
java.naming.provider.url が空の場合や 表示のサーバーすべてにアクセスできない場合、 JNPクライアントはネットワーク上のマルチキャスト呼び出しより HA-JNDI サーバーをディスカバリしようとします (自動ディスカバリ)。 JNDI サーバーノード上で自動ディスカバリを設定する方法は、 「JBoss の設定」 を参照してください。 自動ディスカバリにより、 設定がなくてもクライアントは有効な HA-JNDI サーバーを取得することができる場合があります。 自動ディスカバリが動作させるには、クライアントとサーバークラスター間のネットワークセグメントを設定し、このようなマルチキャストデータグラムを伝搬するようにしなければなりません。
注記
java.naming.provider.url プロパティだけでなく、 他のプロパティセットも指定することもできます。 次の一覧は、 新規の InitialContext を作成する時に指定できるクラスタリング関係のクライアント側プロパティになります (通常の JNDI と共に使用されるすべての標準的な非クラスタリング関連環境プロパティも使用できます)。
java.naming.provider.url: クラスター内の HA-JNDI プロバイダーノード群の IP アドレスとポート番号の一覧を提供します。 クライアントはプロバイダーを 1 つずつ確認し、 最初に応答するプロバイダーを使用します。jnp.disableDiscovery:trueが指定されると自動ディスカバリ機能が無効になります。デフォルトではfalseが指定されます。jnp.partitionName: 異なるクラスター (パーティション) にバインドされる複数の HA-JNDI サービスが実行されている環境でこのプロパティを使用すると、 クライアントが希望するパーティションのサーバーからの自動ディスカバリ応答のみを受け入れるようにできます。自動ディスカバリ機能を使用しない場合は (jnp.disableDiscovery が true の場合など)、このプロパティは使用されません。 デフォルトでは、 このプロパティは設定されず、クラスターパーティション名に関係なく最初に応答する HA-JNDI サーバーが自動のディスカバリ機能によって選択されます。jnp.discoveryTimeout: 自動ディスカバリパケットへの応答に対するコンテキストの待ち時間を指定します。 デフォルトは 5000 ミリ秒です。jnp.discoveryGroup: 自動ディスカバリに使用されるマルチキャストグループアドレスを指定します。 デフォルト値は 230.0.0.4 です。 サーバー側 HA-JNDI サービスで設定された AutoDiscoveryAddress の値を一致しなければなりません。 サーバー側の HA-JNDI サービスは、 デフォルトでは-u起動スイッチより指定されたアドレス上でリッスンします。 そのため、 サーバー側で-uが使用される場合 (推奨通り)、 クライアント側で jnp.discoveryGroup を設定する必要があります。jnp.discoveryPort: 自動ディスカバリに使用されるマルチキャストポートを指定します。 デフォルト値は 1102 です。 サーバー側 HA-JNDI サービスで設定された AutoDiscoveryPort の値と一致しなければなりません。jnp.discoveryTTL: 自動ディスカバリ IP マルチキャストパケットの TTL (time-to-live) を指定します。 この値は、ネットワーク装置がマルチキャストパケットをドロップする前にマルチキャストパケットが伝搬できるネットワークホップ数を表します。 名前とは異なり、時間の単位を表すものではありません。
21.3. JBoss の設定 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/all/deploy/cluster ディレクトリの hajndi-jboss-beans.xmlファイルには、HA-JNDI サービスを有効にする次の Bean が含まれています。
- HAPartition は、 HA-JNDI のクラスター化プロキシの管理や、 別のノードにてローカルでバインドされたオブジェクトを検索するグループ RPC の作成に使用されるコアのクラスタリングサービスを許可します。 詳細は、 「HAPartition サービス」 を参照してください。
- distributedTreeManager は、 レプリケートされたツリーのハンドラーを許可します。 標準的なハンドラは、 JBoss Cache を使用してレプリケートされたツリーを管理します。 挿入された
HAPartitionCacheHandlerBean を使用して JBoss Cache インスタンスが読み出しされます。 詳細は 「HAPartition サービス」 を参照してください。 - localNamingInstance はローカル JNDI サービスへの参照を許可します。
- LookupPool は、 ブートストラップや自動ディスカバリのルックアップを処理するスレッドを提供するために使用するスレッドプールを許可します。
- bindAddress は、 JNP クライアントからネーミングプロキシダウンロードリクエストをリッスンするために HA-JNDI サーバーがバインドするアドレスを指定します。 デフォルト値は
jboss.bind.addressシステムプロパティの値になります。jboss.bind.addressシステムプロパティが設定されていない場合は、localhostがデフォルト値になります。 JBoss 起動時に-bコマンドラインスイッチが使用されるとjboss.bind.addressシステムプロパティが設定されます。 - port は、 JNP クライアントからネーミングプロキシダウンロード要求をリッスンするために HA-JNDI サーバーがバインドするポートを指定します。 値は
conf/bootstrap/bindings.xmlに設定されている ServiceBindingManager Bean より取得されます。 デフォルト値は1100です。 - backlog は、 サービスが JNP クライアントからのネーミングプロキシダウンロード要求をリッスンする TCP サーバーソケットに対する受信接続指示の最大キュー長を指定します。 デフォルト値は
50です。 - rmiBindAddress は、 ネーミングプロキシからの RMI 要求 (JNDI ルックアップに対してなど) をリッスンするために HA-JNDI サーバーがバインドするアドレスを指定します。 デフォルト値は
jboss.bind.addressシステムプロパティの値になります。jboss.bind.addressシステムプロパティが設定されていない場合は、localhostがデフォルト値になります。 JBoss 起動時に-bコマンドラインスイッチが使用されるとjboss.bind.addressシステムプロパティが設定されます。 - rmiPort は、 ダウンロードされたスタブと通信するためにサーバーがバインドするポートを指定します。
conf/bootstrap/bindings.xmlに設定された ServiceBindingManager Bean より値が取得されます。 デフォルト値は1101です。 設定された値がない場合、 オペレーティングシステムが自動的にポートを割り当てます。 - discoveryDisabled は、 自動ディスカバリマルチキャストリスナの設定を無効にするブール変数フラグです。 デフォルトは
falseです。 - autoDiscoveryAddress JNDI 自動ディスカバリのためにリッスンするマルチキャストアドレスを指定します。デフォルト値は、
jboss.partition.udpGroupシステムプロパティの値になります。このシステムプロパティが設定されていない場合は、 230.0.0.4 がデフォルト値となります。 JBoss 起動時に-uコマンドラインスイッチが使用されるとjboss.partition.udpGroupシステムプロパティが設定されます。 - autoDiscoveryGroup は、 JNDI 自動ディスカバリパケットのためにリッスンするポートを指定します。 デフォルト値は
1102です。 - AutoDiscoveryBindAddress は HA-JNDI が 自動ディスカバリ要求パケットをリッスンするインターフェースを設定します。 この属性が指定されておらず
bindAddressが指定されている場合、bindAddressが使用されます。 - autoDiscoveryTTL は自動ディスクカバリ IP マルチキャストパケットの TTL (time-to-live) を指定します。 この値は、ネットワーク装置がマルチキャストパケットをドロップする前にマルチキャストパケットが伝搬できるネットワークホップ数を表します。 名前とは異なり、時間の単位を表すものではありません。
- loadBalancePolicy は、 クライアントプロキシに含まれるべきである LoadBalancePolicyimplementation のクラス名を指定します。 詳細は、 紹介とクイックスタート章を参照してください。
- clientSocketFactory は、 クライアントソケットの作成に使用される
java.rmi.server.RMIClientSocketFactoryの完全修飾クラス名を指定する任意の属性です。 デフォルトはnullです。 - serverSocketFactory は、 サーバーソケットの作成に使用される
java.rmi.server.RMIServerSocketFactoryの完全修飾クラス名を指定する任意の属性です。 デフォルトはnullです。
21.3.1. 2 つ目の HA-JNDI サービスの追加 リンクのコピーリンクがクリップボードにコピーされました!
第22章 クラスター化されたセッション EJB リンクのコピーリンクがクリップボードにコピーされました!
22.1. EJB 3.0 のステートレスセッション Bean リンクのコピーリンクがクリップボードにコピーされました!
@Clustered アノテーションを用いて、 Bean クラスにアノテーションを付けます。 このアノテーションには、 負荷分散ポリシーと使用するパーティションの両方を上書きするオプションのパラメーターが含まれます。
- partition は、 Bean が参加するクラスタの名前を指定します。
@Clusteredアノテーションで、個別の Bean に対してデフォルトパーティションDefaultPartitionを上書きできますが、jboss.partition.nameシステムプロパティを使用するとすべての Bean に対して上書きできます。 - loadBalancePolicy は、 クラスターのノード上の呼び出しを Bean スタブが分散する方法を示し、
org.jboss.ha.client.loadbalance.LoadBalancePolicyを実装するクラス名を定義します。 デフォルト値LoadBalancePolicyは、セッション Bean タイプのデフォルトポリシーを示す特別なトークンです。 ステートレスセッション Bean のデフォルトポリシーはorg.jboss.ha.client.loadbalance.RoundRobinです。 独自の実装を使用してデフォルト値を上書き、あるいは使用できるポリシーのリストより選択することができます。org.jboss.ha.client.loadbalance.RoundRobin- 無作為のターゲットから開始し、 負荷分散を最大限にするため、 常にリスト上で次に利用できるターゲットを選択しようとします。
org.jboss.ha.client.loadbalance.RandomRobin- 以前に選択されたターゲットを考慮せずに、 無作為にターゲットを選択します。
org.jboss.ha.client.loadbalance.aop.FirstAvailable- ターゲットが選択されると、 同じターゲットを選択しようとします (これ以上負荷分散が行われません)。 ステートフルセッション Bean など、「スティッキーセッション」動作が望まれる場合に便利です。
org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxiesFirstAvailableと似ていますが、 希望のターゲットがすべてのプロキシで共有されます。
@Clustered アノテーションを使用する代わりに、 jboss.xml のセッション Bean に対してクラスタリングを有効にすることもできます。
注記
<clustered>True</clustered> 要素は conf/standardjboss.xml ファイルの <configuration-name>Clustered Stateless SessionBean</configuration-name> 要素のエイリアスにすぎません。
@Clustered アノテーションからの対応するプロパティと一致します。
22.2. EJB 3.0 でのステートフルセッション Bean リンクのコピーリンクがクリップボードにコピーされました!
22.2.1. EJB アプリケーション設定 リンクのコピーリンクがクリップボードにコピーされました!
@Cluster アノテーションのタグを付ける必要があります。 ステートレスセッション Bean と異なり、 ステートフルセッション Bean のメソッド呼び出しは、 デフォルトで org.jboss.ha.client.loadbalance.aop.FirstAvailable を使用して負荷分散されます。 このポリシーを使用してメソッド呼び出しが無作為に選択されたノードに従います。
@org.jboss.ejb3.annotation.CacheConfig アノテーションを Bean に適応してデフォルトのキャッシング動作を上書きすることもできます。 @CacheConfig アノテーションの定義は次の通りです。
nameは、 「CacheManager サービスの設定」 で説明したCacheManagerサービスで登録されたキャッシュ設定の名前を指定します。 デフォルトでは、sfsb-cache設定が使用されます。maxSizeは、LRU アルゴリズムを使用して Bean の非活性化を開始する前にキャッシュできる Bean の最大数を指定します。idleTimeoutSecondsはキャッシュが Bean を非活性化する前に Bean が未使用の状態でいられる最大時間を指定します (maxSize Bean がキャッシュされているかは無関係)。removalTimeoutSecondsは、キャッシュが Bean を削除するまで Bean を使用しない最大時間を指定します。replicationIsPassivationは、キャッシュでレプリケーションを非活性化と同等であると見なし、Bean に対して @PrePassivate と @PostActivate のコールバックを呼び出すかどうかを指定します。デフォルトでは真であり、レプリケーションには Bean のシリアル化が関係するため、シリアル化の準備とシリアル化からの回復がコールバックメソッドを実装する一般的な理由となります。
22.2.2. ステートレプリケーションの最適化 リンクのコピーリンクがクリップボードにコピーされました!
public interface Optimized
{
boolean isModified();
}
public interface Optimized
{
boolean isModified();
}
Optimized メソッドを実装するかをコンテナーがチェックします。 この場合、 コンテナーがisModified() メソッドを呼び出し、 メソッドが true を返した場合のみ Bean をレプリケートします。 Bean が変更されていない場合 (またはユーザーの希望により十分な変更でないためレプリケーションが必要ない場合) は、 false を返すことができます。 この場合、 レプリケーションは発生しません。
22.2.3. CacheManager サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
CacheManager サービスは JBoss Cache インスタンスのファクトリでもありレジストリでもあります。 次の通り、 ステートフルセッション Bean はデフォルトで CacheManager より sfsb-cache 設定を使用します。
デフォルトの SFSB キャッシュはエビクションをサポートするよう設定されます。 EJB3 SFSB コンテナーは JBoss Cache エビクションメカニズムを使用して SFSB 非活性化を管理します。 Bean がデプロイされた場合、 EJB コンテナーはプログラムを使用してキャッシュにエビクションリージョンを追加します (1 つの Bean タイプに対して 1 つのリージョン)。
JBoss Cache CacheLoader も設定し、SFSB 非活性化を再度サポートします。Bean がキャッシュから除外されると、キャッシュローダーは永続ストアに Bean を非活性化します (この場合は ディレクトリのファイルシステムに行います)。JBoss Cache は、様々な CacheLoader 実装に対応しており、これらの実装はあらゆる永続ストアタイプへデータを格納する方法を認識します。詳細については、JBoss Cache のドキュメントを参照してください。ただし、CacheLoaderConfiguration を変更する場合は、共有されたストア (共有されたデータベースの単一のスキーマなど) を使用しないようにしてください。クラスター内の各ノードは独自の永続ストアを持つ必要があります。そうでないと、ノードは個別でクラスター化された Bean を非活性化および活性化するため、ノードがそれぞれのデータを破損してしまいます。
$JBOSS_HOME /server/all/data/sfsb
バディーレプリケーションを使用すると、クラスターのすべてのサーバーではなく、 クラスタで設定可能な数のバックアップサーバー (バディー) へステートがレプリケートされます。 バディーレプリケーションを有効にするには、 buddyReplicationConfig プロパティ Bean の次のプロパティを調整します。
enabledをtrueに設定します。- n
buddyPoolNameを使用してクラスター内でノードの論理サブグループを形成します。 可能な場合、 同じバディープールのノードよりバディーが選択されます。 - 各ノードがステートをレプリケートするバックアップノードの数に合わせ、
buddyLocatorConfig.numBuddiesプロパティを調整します。
22.3. EJB 2.x のステートレスセッション Bean リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml 記述子を変更し、 <clustered> タグが含まれるようにする必要があります。
- partition-name は、Bean が参加するクラスターの名前を指定します。デフォルト値は
DefaultPartitionです。デフォルトのパーティション名は、jboss.partition.nameシステムプロパティを使用してシステム全体で設定することもできます。 - home-load-balance-policy は、 クラスターのノードへの呼び出しを分散するためにホームスタブが使用するクラスを指定します。 デフォルトでは、 プロキシは
RoundRobinを用いて呼び出しの負荷を分散します。 - bean-load-balance-policy は、クラスターのノードへの呼び出しを分散するために Bean スタブが使用するクラスを指定します。 デフォルトでは、 プロキシは
RoundRobinを用いて呼び出しの負荷を分散します。
22.4. EJB 2.x のステートフルセッション Bean リンクのコピーリンクがクリップボードにコピーされました!
HASessionStateService Bean を使用してクラスター化された EJB 2.x ステートフルセッション Bean の分散セッションステートを管理します。 この項では、 セッション Bean 設定と HASessionStateService Bean 設定の両方について説明します。
22.4.1. EJB アプリケーション設定 リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml 記述子ファイルを変更し、<clustered> タグを追加する必要があります。
<clustered> タグが必須です。<cluster-config> 要素はオプションであり、そのデフォルトの属性値は上記と同じ設定で指定されます。
<session-state-manager-jndi-name> タグは、この Bean が使用する HASessionStateService サービスの JNDI 名を提供するために使用されます。
22.4.2. ステートレプリケーションの最適化 リンクのコピーリンクがクリップボードにコピーされました!
public boolean isModified();
public boolean isModified();
isModified() メソッドを呼び出し、 メソッドが true を返した場合のみ Bean をレプリケートします。 Bean が変更されていない場合 (またはユーザーの希望により十分な変更でないためレプリケーションが必要ない場合) は、 false を返すことができます。 この場合、 レプリケーションは発生しません。
22.4.3. The HASessionStateService サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
HASessionStateService Bean は $JBOSS_HOME/server/PROFILE/deploy/cluster/ha-legacy-jboss-beans.xmlファイルで定義されます。
HASessionStateService Bean の設定属性は次の通りです。
- HAPartition は HA-JNDI がクラスター内の通信に使用する HAPartition サービスを挿入する必須属性です。
- JndiName は、 この
HASessionStateServiceサービスがバインドされる JNDI 名を指定するオプションの属性です。 デフォルト値は/HAPartition/Defaultになります。 - BeanCleaningDelay はオプションの属性で、 指定された時間 (ミリ秒単位) が経過した後に
HASessionStateServiceが変更されていないステートを消去します。 Bean を所有するノードがクラッシュすると、 その兄弟ノードがこの Bean を所有することになります。 兄弟ノードのコンテナキャッシュはそれを認識しないため、 Bean の消去設定に基づいて消去することはできません。 そのため、HASessionStateServiceが時々クリーンアップを行う必要があります。 デフォルト値は30*60*1000ミリ秒 (30 分) です。
22.4.4. クラスター再起動の処理 リンクのコピーリンクがクリップボードにコピーされました!
22.4.5. JNDI ルックアッププロセス リンクのコピーリンクがクリップボードにコピーされました!
- また独自の静的 retryEnv フィールドも調べます。 このフィールドは RetryInterceptor.setRetryEnv(Properties) の呼び出しを用いてクライアントコードより設定できますが、 この設定方法には 2 つの欠点があります。 1 つ目の欠点は、 JBoss 固有の呼び出しをクライアントコードに導入することによって移植性が減少することです。もう 1 つの欠点は、静的フィールドが使用されているため 1 つの JVM に対して 1 つの設定しか使用できないことです。
- retryEnv フィールドが null の場合は、org.jboss.naming.NamingContextFactory クラスによって ThreadLocal にバインドされた環境プロパティがチェックされます。このクラスをネーミングコンテキストファクトリとして使用するには、jndi.properties でプロパティ java.naming.factory.initial=org.jboss.naming.NamingContextFactory を適切に設定します。この利点は org.jboss.naming.NamingContextFactory を jndi.properties ファイルの設定オプションで簡単に使用できるため、java コードが影響を受けないことです。欠点はネーミングプロパティが ThreadLocal に格納されるため、InitialContext を最初に作成したスレッドに対してのみ可視の状態にあることです。
- 上記のいずれの方法でもネーミング環境プロパティが設定されない場合はデフォルトの InitialContext が使用されます。 ネーミングサーバーへ接続できない場合、 デフォルトでは HA-JNDI ネーミングサーバーを検索するため InitialContext がマルチキャストディスカバリへフォールバックしようとします。 HA-JNDI のマルチキャストディスカバリの詳細は、 21章クラスター化 JNDI サービス を参照してください。
22.4.6. SingleRetryInterceptor リンクのコピーリンクがクリップボードにコピーされました!
第23章 クラスター化した Entity EJB リンクのコピーリンクがクリップボードにコピーされました!
23.1. EJB 3.0 内の エンティティ Bean リンクのコピーリンクがクリップボードにコピーされました!
23.1.1. 分散型キャッシュの設定 リンクのコピーリンクがクリップボードにコピーされました!
- キャッシュが有効になっている エンティティ Bean インスタンスをエンティティマネージャーを用いてデータベースへ永続化させると、 エンティティはキャッシュの中に挿入されます。
- エンティティ Bean インスタンスを更新し、その変更をエンティティマネージャーよりデータベースに保存すると、エンティティはキャッシュ内で更新されます。
- エンティティ Bean インスタンスをエンティティマネージャーを用いてデータベースから削除すると、 そのエンティティはキャッシュから削除されます。
- エンティティマネージャーを介してデータベースからキャッシュ化したエンティティを ロードする時、そのエンティティがデータベース内にまだ存在しない場合、そのエンティティは キャッシュに挿入されます。
persistence.xml より設定されます。
- hibernate.cache.use_second_level_cache
- エンティティとコレクションの 2 次キャッシングを有効にします。
- hibernate.cache.use_query_cache
- クエリの 2 次キャッシングを有効にします。
- hibernate.cache.region.factory_class
- リージョン固有のキャッシング動作を指示する
RegionFactory実装を定義します。 Hibernate には、共有と多重の 2 種類の JBoss Cache ベース 2 次キャッシュが同梱されています。共有リージョンファクトリは全てのキャッシュリージョンに同じキャッシュを使用します。 これは、 以前の Hibernate バージョンのレガシー CacheProvider 実装の動作と同様です。Hibernate には 2 つの共有リージョンファクトリ実装が同梱されています。- org.hibernate.cache.jbc2.SharedJBossCacheRegionFactory
- 全てのキャッシュリージョンに対し、 新たにインスタンス化された CacheManager より単一の JBoss Cache 設定を使用します。
Expand 表23.1 SharedJBossCacheRegionFactory のその他のプロパティ プロパティ デフォルト 詳細 hibernate.cache.region.jbc2.cfg.shared treecache.xml JBoss Cache 設定が含まれるクラスパスまたはファイルシステムリソースです。 hibernate.cache.region.jbc2.cfg.jgroups.stacks org/hibernate/cache/jbc2/builder/jgroups-stacks.xml JGroups プロトコルスタック設定が含まれるクラスパスまたはファイルシステムリソースです。 - org.hibernate.cache.jbc2.JndiSharedJBossCacheRegionFactory
- 全てのキャッシュリージョンに対し、 既存の JNDI へバインドされた既存の CacheManager より単一の JBoss Cache 設定を使用します。
Expand 表23.2 JndiSharedJBossCacheRegionFactory のその他のプロパティ プロパティ デフォルト 詳細 hibernate.cache.region.jbc2.cfg.shared Required 共有 Cacheインスタンスがバインドされる JNDI 名です。
多重リージョンファクトリは、 各キャッシュリージョンに対して最適化された設定を使用し、 個別のキャッシュインスタンスを使用します。Expand 表23.3 多重リージョンファクトリ実装の一般的なプロパティ プロパティ デフォルト 詳細 hibernate.cache.region.jbc2.cfg.entity optimistic-entity エンティティキャッシュリージョンに使用される JBoss Cache 設定です。 この他に、 mvcc-entity、 pessimistic-entity、 mvcc-entity-repeatable、 optimistic-entity-repeatable、p essimistic-entity-repeatable を設定することができます。 hibernate.cache.region.jbc2.cfg.collection optimistic-entity コレクションキャッシュリージョンに使用される JBoss Cache 設定です。 通常、 コレクションキャッシュリージョンはエンティティキャッシュリージョンと同じ設定を使用します。 hibernate.cache.region.jbc2.cfg.query local-query クエリキャッシュリージョンに使用される JBoss Cache 設定です。 デフォルトでは、 キャッシュされたクエリ結果はレプリケートされません。 この他に、 replicated-query を設定することができます。 hibernate.cache.region.jbc2.cfg.ts timestamps-cache タイムスタンプキャッシュリージョンに使用される JBoss Cache 設定です。 クエリキャッシングが使用される場合、 クエリキャッシュがレプリケートしなくても、 対応するタイムスタンプキャッシュはレプリケートしなければなりません。 タイムスタンプキャッシュリージョンはクエリキャッシュと同じキャッシュを共有してはいけません。 Hibernate には 2 つの共有リージョンファクトリ実装が同梱されています。- org.hibernate.cache.jbc2.MultiplexedJBossCacheRegionFactory
- キャッシュリージョン毎に、 新たにインスタンス化された CacheManager より個別の JBoss Cache 設定を使用します。
Expand 表23.4 MultiplexedJBossCacheRegionFactory のその他のプロパティ プロパティ デフォルト 詳細 hibernate.cache.region.jbc2.configs org/hibernate/cache/jbc2/builder/jbc2-configs.xml JBoss Cache 設定が含まれるクラスパスまたはファイルシステムリソースです。 hibernate.cache.region.jbc2.cfg.jgroups.stacks org/hibernate/cache/jbc2/builder/jgroups-stacks.xml JGroups プロトコルスタック設定が含まれるクラスパスまたはファイルシステムリソースです。 - org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory
- キャッシュリージョン毎に、 JNDI にバインドされた CacheManager より個別の JBoss Cache 設定を使用します。 「JBoss Enterprise Application Platform の CacheManager サービス」 を参照してください。
Expand 表23.5 JndiMultiplexedJBossCacheRegionFactory のその他のプロパティ プロパティ デフォルト 詳細 hibernate.cache.region.jbc2.cachefactory Required CacheManagerインスタンスがバインドされる JNDI 名です。
23.1.2. キャッシュ用の エンティティ bean の設定 リンクのコピーリンクがクリップボードにコピーされました!
@org.hibernate.annotations.Cache アノテーションを使用します。
jboss-cache-manager-jboss-beans.xml など) にある各エンティティ Bean に対してキャッシュを細かく調整することができます。 例えば、 キャッシュのサイズを指定することができます。 キャッシュ内にあるオブジェクトが多すぎる場合、 キャッシュは設定通りに最も古いオブジェクトや使用頻度が最も低いオブジェクトをエビクトして新しいオブジェクトのスペースを確保することができます。 例えば、 persistence.xml で指定された region_prefix が myprefix である場合、 com.mycompany.entities.Account エンティティ bean のキャッシュリージョンのデフォルト名は /myprefix/com/mycompany/entities/Account になります。
defaultEvictionRegionConfig を使用してそのクラスのすべてのインスタンスがキャッシュされます。 エンティティクラスの完全修飾名より自動的に作成するのではなく、 @Cache アノテーションは、 エンティティが保存されるキャッシュリージョンを指定できるようにする任意の属性「region」を公開します。
23.1.3. クエリ結果のキャッシュ リンクのコピーリンクがクリップボードにコピーされました!
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
persistence.xml でリージョンのプレフィックスが myprefix に設定されている場合は、 以下のようなエビクション処理を作成できます。
23.2. EJB 2.x 内の Entity Bean リンクのコピーリンクがクリップボードにコピーされました!
<clustered> 要素をアプリケーションの jboss.xml 記述子ファイルに追加する必要があります。 以下に標準的な jboss.xml ファイルを示します。
<row-lock> 参照)、 JDBC ドライバーのトランザクション分離レベルを TRANSACTION_SERIALIZABLE に設定するしか方法はありません。 サポートされる分散型ロッキングメカニズムや分散型キャッシュがないため、 エンティティ Bean は、デフォルトでコミットオプション 「B」 を使用します。 (standardjboss.xml と コンテナー設定 Clustered CMP 2.x EntityBean、 Clustered CMP EntityBean、 Clustered BMP EntityBean を参照)。 エンティティ Bean が読み込み専用でない場合は、 コミットオプション 「A」 の使用は推奨できません 。
注記
第24章 HTTP サービス リンクのコピーリンクがクリップボードにコピーされました!
第25章 JBoss Messaging のクラスタリングに関する注意 リンクのコピーリンクがクリップボードにコピーされました!
第26章 クラスター化されたデプロイメントのオプション リンクのコピーリンクがクリップボードにコピーされました!
26.1. クラスター化シングルトンサービス リンクのコピーリンクがクリップボードにコピーされました!
図26.1 マスターノードで障害が発生する前のトポロジ
図26.2 マスターノードで障害が発生した後のトポロジ
26.1.1. HASingleton デプロイメントオプション リンクのコピーリンクがクリップボードにコピーされました!
HAPartition を使用してクラスター内の異なるノードが起動および停止した時に通知を行います。 これらの通知に基づいて、 クラスター内の各ノードは独自に (また一貫的に) マスターノードであるかを判断し、 サービスの提供を開始するかを決定します。
26.1.1.1. HASingletonDeployer サービス リンクのコピーリンクがクリップボードにコピーされました!
deploy の代わりに $JBOSS_HOME/server/production/deploy-hasingleton ディレクトリにデプロイすることです。deploy-hasingleton ディレクトリは deploy や farm ディレクトリに含まれないため、そのコンテンツは Enterprise Application Platform インスタンスの起動時に自動的にデプロイされません。 このディレクトリのコンテンツをデプロイするのは HASingletonDeployer bean (これ自体は deploy/deploy-hasingleton-jboss-beans.xml ファイルによってデプロイされます) という特殊なサービスです。 HASingletonDeployer サービスはそれ自体が HA シングルトンであり、マスターになった時にその提供されたサービスは deploy-hasingleton のコンテンツをデプロイし、マスターでなくなったとき (通常はサーバーのシャットダウン時) にそのサービスは deploy-hasingleton のコンテンツをアンデプロイします。
deploy-hasingleton に格納することにより、デプロイメントはクラスター内のマスターノードにのみデプロイされます。マスターノードが正常にシャットダウンした場合は、シャットダウンの一部としてデプロイメントが正常にデプロイ解除されます。マスターノードで障害が発生した場合やマスターノードがシャットダウンされた場合はこのデプロイメントがマスターとして引き継いだノードにデプロイされます。
deploy-hasingletonのサービスにはホットデプロイメント機能がありません。deploy-hasingletonにデプロイされたサービスを再デプロイするにはサーバーを再起動する必要があります。- マスターノードで障害が発生し、 別のノードがマスターを引き継いだ場合、 シングルトンサービスはサービスを提供する前にデプロイメントプロセス全体を経る必要があります。 サービスのデプロイメントの複雑さや実行する開始アクティビティの種類によって異なりますが、 処理にしばらく時間がかかることがあります 。処理中はサービスが提供されません。
26.1.1.2. HASingletonController を使用した POJO デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
public interface HASingletonExampleMBean
{
boolean isMasterNode();
}
public interface HASingletonExampleMBean
{
boolean isMasterNode();
}
startSingleton と stopSingleton になっていますが、 メソッドには任意の名前を付けることができます。
META-INF/jboss-service.xml と共に .sar ファイルにパッケージされています。
deploy または farm に格納できるため、 ホットデプロイメントやファームデプロイメントを実行できることです。 また、 このサービス例が複雑で時間がかかる起動要件を持っている場合、 create() メソッドまたは start() メソッドで実装することが可能です。 サービスがデプロイされると、 JBoss は即座に create() と start() を呼び出します。 ノードがマスターノードになるまで待機しないため、 コントローラーが startSingleton() を実装するまで待機すれば、サービスはすぐに利用できる状態になります。
HASingletonController は目的の起動メソッドや停止メソッドに対するオプションの引数をサポートします。 引数を指定するには、 起動メソッドの場合は targetStartMethodArgument プロパティを使用し、 停止メソッドの場合は TargetStopMethodArgument プロパティを使用します。 現在、 ストリング値のみがサポートされています。
26.1.1.3. バリアを使用した HASingleton デプロイメント リンクのコピーリンクがクリップボードにコピーされました!
<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
注記
BarrierController が破棄あるいはデプロイ解除された時のみ発生するサービスの破棄については制御しません。 そのため、サービスの通常のデプロイ解除操作として Barrier を使用し、破棄しなければならないサービスを制御しようとしても (EJBContainer など)、 思い通りには動作しません。
26.1.2. マスターノードの決定 リンクのコピーリンクがクリップボードにコピーされました!
jboss:service=DefaultPartition MBean の CurrentView 属性を確認します。 クラスターの各メンバーは同じビューを持ち、 メンバーの順番も同じです。
HASingletonController など) があるとします。 HAPartition サービスはどのサービスがどこにデプロイされているかをビューの順序で表すレジストリをクラスター全体で保持します。 したがって、クラスター内の各ノードでは、HAPartition サービスは Foo サービスに関するビューが {A, C, D} (B はなし) であることを認識します。
HAPartition サービスは Foo へのコールバックを呼び出し、 新しいトポロジについて通知します。 例えば、 Foo が D で起動した時に、 A、 C、 D で実行されているすべての Foo サービスが、 Foo の新しいビューが {A, C, D} であると通知するコールバックを受け取ったとします。 この場合、コールバックにより、各ノードが独自にマスターであるかを判断できる十分な情報をノードに提供します。 「HA シングルトンの選出ポリシー」 の通り、 各ノードの Foo サービスは HAPartition の HASingletonElectionPolicy を使用してマスターであるかを判断します。
26.1.2.1. HA シングルトンの選出ポリシー リンクのコピーリンクがクリップボードにコピーされました!
HASingletonElectionPolicy オブジェクトは、 クラスタートポロジの変更後、 HA シングルトンの代わりに利用可能なノードのリストからマスターノードを選出します。
public interface HASingletonElectionPolicy
{
ClusterNode elect(List<ClusterNode> nodes);
}
public interface HASingletonElectionPolicy
{
ClusterNode elect(List<ClusterNode> nodes);
}
HASingletonElectionPolicySimple- このポリシーはマスターノードを相対年代で選択します。 希望の年代は、 利用可能ノードリストのインデックスに相当する
positionプロパティより設定します。position = 0はデフォルトで最も古いノードを意味し、position = 1は 2 番目に古いノードを意味します。positionに負の数字を使用してノードの新しさを示すこともできます 。利用可能ノードのリストは環状リストであると考えてみてください。position = -1は最新のノードを意味し、position = -2は 2 番目に新しいノードを意味します。<bean class="org.jboss.ha.singleton.HASingletonElectionPolicySimple"> <property name="position">-1</property> </bean>
<bean class="org.jboss.ha.singleton.HASingletonElectionPolicySimple"> <property name="position">-1</property> </bean>Copy to Clipboard Copied! Toggle word wrap Toggle overflow PreferredMasterElectionPolicy- このポリシーは、
HASingletonElectionPolicySimpleを拡張し、 希望のノードを設定できるようにします。 host:port または address:port と指定されたpreferredMasterプロパティは、 使用できる場合にマスターとなるべきノードを特定します。 希望のノードが使用できない場合、 選出ポリシーが前述の通り動作します。<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy"> <property name="preferredMaster">server1:12345</property> </bean>
<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy"> <property name="preferredMaster">server1:12345</property> </bean>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
26.2. ファーミングデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
all/farm/ ディレクトリへデプロイすることができます。 アプリケーションは自動的に同じクラスター内の全ノードで複製されます。 ノードが後にクラスタに参加する場合、 クラスター内のファーミングデプロイされたアプリケーションがすべてプルインされ起動時にローカルにデプロイされます。 実行中のクラスター化されたサーバーノードの farm/ ディレクトリよりアプリケーションを削除すると、 アプリケーションはローカルでアンデプロイされ、 他すべてのクラスター化されたサーバーノードにある farm/ ディレクトリより削除されます (アンデプロイがトリガされます)。
all 設定ではファーミングがデフォルトで有効になっているため、 自分で設定する必要はありません。必須の farm-deployment-jboss-beans.xml 設定ファイルと timestamps-jboss-beans.xml 設定ファイルは deploy/cluster ディレクトリにあります。カスタム設定でファーミングを有効にしたい場合は JBoss deploy ディレクトリ $JBOSS_HOME/server/$your_own_config/deploy/cluster にこれらのファイルをコピーするだけです。 カスタム設定ではクラスタリングが有効になっているようにしてください。
FarmProfileRepositoryClusteringHandler Bean よりカスタマイズすることができます。 プロパティとデフォルト値は次のようになります。
- partition は必須の属性で、 クラスター内の通信でファームサービスが使用する HAPartition サービスを挿入します。
- profile[Domain|Server|Name] は、 このハンドラーが目的とするサーバープロファイルを特定するのに使用されます。
- immutable は、 ノードがコンテンツの変更をクラスターへプッシュすることを許可するかを示します。
trueの値は、synchronizationPolicyをorg.jboss.system.server.profileservice.repository.clustered.sync.ImmutableSynchronizationPolicyに設定することに相当します。 - lockTimeout はクラスター全体のロック取得に対して待機する時間 (ミリ秒単位) を定義します。
- methodCallTimeout は、 リモートクラスターノード上の呼び出しに対して待機する時間 (ミリ秒単位) を定義します。
- synchronizationPolicy は、 クラスターへの参加を試みるノードやノードの統合より、 どのようにクラスターコンテンツを追加、 再生、 更新、 削除するかを決定します。 ポリシーは「権限のある」ノード上で確認されます (クラスター上のサービスのマスターノードなど)。 再生 (Reincarnation) は、 新たに起動されたノードの
farmディレクトリに以前ファーミングサービスによって削除されたサービスが存在することで、実行されていない時に削除されると起動するノードに残存することがあります。 デフォルトの synchronizationPolicy は次のように定義されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - allow[Join|Merge][Additions|Reincarnations|Updates|Removals] は、 要求への固定応答を定義し、 結合されたノードや統合されたノードからの追加、再生、更新、削除を可能にします。
- developerMode は、 すべての変更を許可する寛大な同期化ポリシーを有効します。 developerModeを有効にすることは、 上記の各プロパティを
trueに設定することに相当するため 、開発環境用の設定となります。 - removalTrackingTime は、 再生の検知に使用するため、 ポリシーが削除されたアイテムを記憶すべき期間 (ミリ秒単位) を定義します。
- timestampService は、 クラスターの現在および過去のメンバーに対するシステムクロックの不一致を推測し追跡します。 デフォルト実装は
timestamps-jboss-beans.xmlに定義されます。
第27章 JGroups サービス リンクのコピーリンクがクリップボードにコピーされました!
- http://jgroups.org/ug.html の JGroups プロジェクトドキュメント。
- https://www.jboss.org/community/wiki/JGroups に掲載されている jboss.org の JGroups wiki ページ。
27.1. JGroups チャネルのプロトコルスタックを設定 リンクのコピーリンクがクリップボードにコピーされました!
図27.1 JGroups 内のプロトコルスタック
$JBOSS_HOME/server/production/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml ファイル内でネストされた要素として表示されます。このファイルは ChannelFactory サービスによって構文分析され、このコンテンツを使用して、正しく設定されたチャネルを必要とするクラスター化サービスへ提供します。ChannelFactory サービスの詳細は、「チャネルファクトリサービス」 を参照してください。
jgroups-channelfactory-stacks.xml のプロトコルスタック設定例になります。
<config> 要素にはすべての JGroups 設定データが含まれます。 この情報は、 概念的にソケットと似ている JGroups チャネルの設定に使用され、 クラスターのピア間の通信を管理します。 <config> 要素内部の各要素は特定の JGroups プロトコルを定義します。 各プロトコルは 1 つの機能を実行し、 これらの機能の組み合わせによってチャネル全体の特性が定義されます。 今後の項では、一般的に使用されるプロトコルやオプションについて説明し、 各プロトコルに使用できるオプションについて取り上げます。
27.1.1. 一般的な設定プロパティ リンクのコピーリンクがクリップボードにコピーされました!
statsは、 AS の JMX コンソールや JGroups Probe ユーティリティなどのツールによって公開される操作に対するランタイム統計をプロトコルが収集するかを判断します。 収集される統計はプロトコルによって異なります。 デフォルトはtrueになります。
注記
down_thread 属性と up_thread 属性を公開しました。 JBoss Application Server 5 とそれ以降のバージョンに含まれる JGroups のバージョンはこれら属性を使用しません。 また、 これらの属性がプロトコルに対して設定されると、 WARN メッセージがサーバーログに書き込まれます。
27.1.2. トランスポートプロトコル リンクのコピーリンクがクリップボードにコピーされました!
UDP、 TCP、 TUNNEL をサポートします。
注記
UDP、 TCP、 TUNNEL プロトコルは相互に排他的です。 各 JGroups Config エレメントには 1 つのトランスポートプロトコルのみを指定できます。
27.1.2.1. UDP 設定 リンクのコピーリンクがクリップボードにコピーされました!
config 要素内の UDP サブ要素に設定する必要があります。 例は次の通りです。
UDP プロトコルに使用できる属性を取り上げた後、 TCP プロトコルや TUNNEL プロトコルが使用する属性について説明します。
UDP プロトコル特有の属性は次の通りです。
- ip_mcast は IP マルチキャスト機能を使用するかどうかを指定します。 デフォルト値は
trueです。falseに設定された場合は、 1 つのマルチキャストパケットではなく複数のユニキャストパケットが送信されます。UDPプロトコルより送信されるすパケットはすべて UDP データグラムです。 - mcast_addr はグループ (クラスターなど) との通信に対するマルチキャストアドレス (クラス D) を指定します。 JBoss AS の標準的なプロトコルスタック設定は、 システムプロパティ
jboss.partition.udpGroupの値 (設定されている場合) をこの属性に使用します。 JBoss Application Server の起動時に-uコマンドラインスイッチを使用すると、 この値を設定します。 この設定属性を使用して JGroups チャネルを適切に別のチャネルより分離する方法については、 「JGroups チャネルの分離」 を参照してください。 この属性を省略すると、 デフォルト値は228.11.11.11になります。 - mcast_port はグループとマルチキャスト通信するポートを指定します。 この設定属性を使用して JGroups チャネルを適切に別のチャネルより分離する方法については、 「JGroups チャネルの分離」 を参照してください。 この属性を省略すると、 デフォルト値は
45688になります。 mcast_send_buf_size、mcast_recv_buf_size、ucast_send_buf_size、ucast_recv_buf_sizeは、 JGroups がオペレーティングシステムより要求するソケットの送受信バッファーサイズを指定します。 バッファーサイズを大きくすると、 バッファーのオーバーフローによるパケット落ちを防ぐことができます。 しかし、 ソケットバッファーサイズはオペレーティングシステムレベルで制限されるため、 希望のバッファーサイズを得るにはオペレーティングシステムレベルでの設定が必要となることがあります。 詳細は 「OS UDP の バッファー制限を設定してUDPのパフォーマンスを改善」 を参照してください。- bind_port はユニキャスト受信ソケットがバインドされるポートを指定します。 デフォルトは
0で、 短命ポートを使用します。 - port_range は、
bind_portによって特定されたポートがない場合に試行するポート数を指定します。 デフォルトは1で、bind_portのみが試行されます。 - ip_ttl は、IP マルチキャストパケットの TTL (生存期間) を指定します。TTL は、マルチキャストネットワーキングで一般的に使用される用語ですが、この値はネットワーキング装置がパケットを破棄するまでパケットがネットワークを通過する回数を表すためこの用語は実際には適切ではありません。
- tos はユニキャストおよびマルチキャストデータグラムを送信するトラフィッククラスを指定します。
TCP や TUNNEL で同じ意味を持つ属性は次の通りです。
- singleton_name はトランスポートプロトコル設定に固有の名前を提供します。 アプリケーションサーバーの
ChannelFactoryによって使用され、 同じトランスポートプロトコルを使用する異なるチャネルによるトランスポートプロトコルインスタンスの共有をサポートします。 「JGroups 共有トランスポート」を参照してください。 - bind_addr はメッセージの送受信を行うインターフェースを指定します。 デフォルトでは、 JGroups はシステムプロパティ
jgroups.bind_addrの値を使用します。-bコマンドラインスイッチを使用して設定することもできます。 JGroups ソケットのバインドに関する詳細は、 「その他設定の問題」 を参照してください。 - receive_on_all_interfaces はこのノードがすべてのインターフェースでマルチキャストをリッスンするかを指定します。 デフォルト値は
falseです。 マルチキャストの受信についてはbind_addrプロパティよりも優先されます。 ただし、 マルチキャストの送信には引き続きbind_addr(設定されている場合) が使用されます。 - send_on_all_interfaces は、 マシンに複数のネットワークインターフェースコントローラがある場合に、 このノードがすべてのネットワークインターフェースコントローラから UDP パケットを送信するかどうかを指定します。 同じマルチキャストメッセージが N 回送信されることを意味するため、 注意して使用してください。
- receive_interfaces は、マルチキャストを受信するインターフェースの一覧を指定します。マルチキャスト受信ソケットはこれらのインターフェースすべてでリッスンします。IP アドレスまたはインターフェース名をカンマで区切ったリストになります (例:
192.168.5.1,eth1,127.0.0.1)。 - send_interfacesは、マルチキャストを送信するインターフェースの一覧を指定します。マルチキャスト送信ソケットはこれらのインターフェースすべてでリッスンします。 IP アドレスまたはインターフェース名をカンマで区切ったリストになります (例:
192.168.5.1,eth1,127.0.0.1)。 そのため、同じマルチキャストメッセージが N 回送信されるため、注意して使用してください。 - enable_bundling は、メッセージのバンドルを有効にするかを指定します。
trueの場合、max_bundle_sizeバイトが累積されるかmax_bundle_timeミリ秒が経過するまで (いずれか早く発生する期間) トランスポートプロトコルが送信メッセージをキューに入れます。 次にキューに入ったメッセージを 1 つの大きなメッセージにまとめてから送信します。 このメッセージは受信側で元に戻されます。 デフォルト値はfalseです。メッセージのバンドルは、 送信元が受信先からの応答待機をブロックしない場合 (REPL_ASYNCに対して設定された JBoss Cache インスタンスなど)、 大量のメッセージ送信に使用されるチャネルに対してパフォーマンスの大幅な改善を期待できます。 送信元が応答待機をブロックする必要がある場合、 アプリケーションの待ち時間が大幅に長くなるため、 JBoss Cache インスタンスがREPL_SYNCに設定された場合など、 特定の場合でのみ推奨されます。 - loopback は、 グループにメッセージを送信するスレッド自体が、 配信のためメッセージをスタックに戻すかを指定します (グループに送信されるメッセージは常に送信するノードにも配信されます)。
falseの場合、 送信するスレッドはメッセージを持ちません。 トランスポートプロトコルがネットワークからメッセージを読み取るために待機し、 配信にメッセージ配信プールスレッドの 1 つを使用します。 デフォルトはfalseですが、 ネットワークインターフェースが停止した時にチャネルがメッセージを受信できるようにするためtrueが推奨されます。 - discard_incompatibe_packets は、 別バージョンの JGroups を使用するピアから送信されたパケットを破棄するか指定します。 クラスター内の各メッセージには JGroups バージョンのタグが付けられます。
discard_incompatible_packetsがtrueに設置されると、 別バージョンの JGroups からの受信されたメッセージは静かに破棄されます。 これ以外の場合は警告がログに記録されます。 メッセージは配信されません。 デフォルト値はfalseです。 - enable_diagnostics は、 アドレス
diagnostics_addrとポートdiagnostics_port上でマルチキャストソケットを開け、 JGroup の Probe ユーティリティが送信した分析要求をリッスンするかを指定します。 - 通常の受信メッセージをスタックに運ぶため JGroups が使用するスレッドプールの動作は、 様々な thread_pool 属性が設定します。 これらの属性は、
java.util.concurrent.ThreadPoolExecutorServiceのインスタンスに対してコンストラクターの引数を提供します。 上記の例では、 プールの最低またはコアサイズが 8 スレッドで、 最大サイズは 200 になります。 9 つ以上のプールスレッドが作成されると、 メッセージの伝達より返されたスレッドは、 伝達する新しいメッセージが割り当てられるまで最大 5000 ミリ秒待機し、 その後終了します。 メッセージを伝達するスレッドがない場合、 ソケット外でメッセージを読み取る個別のスレッドがメッセージをキューに入れます。 キューは最大 1000 メッセージを保持することができます。 キューがいっぱいの場合、ソケット外でメッセージを読み取るスレッドはメッセージを破棄します。 - 受信メッセージをプロトコルスタックへ運ぶために使用される
java.util.concurrent.ThreadPoolExecutorServiceを設定するという面で、 oob_thread_pool 属性は thread_pool 属性と似ています。この場合、 OOB (帯域外、Out Of Band) メッセージと呼ばれる特別なタイプのメッセージを運ぶためにプールが使用されます。 OOB メッセージは、 NAKACK や UNICAST などのプロトコルの順番配信要件を免除されるため、 NAKACK や UNICAST が特定送信元のメッセージをキューに入れている場合でも、 OOB メッセージはスタックへ配信されます。 OOB メッセージは JGroups プロトコルによって頻繁に内部で使用され、 アプリケーションによって使用されることもあります。 例えば、 JBoss Cache がREPL_SYNCモードである場合、 2 フェーズコミットプロトコルの第 2 フェーズ にOOB メッセージを使用します。
27.1.2.2. TCP 設定 リンクのコピーリンクがクリップボードにコピーされました!
config 要素内の TCP 要素を定義してください。 TCP 要素の例は次の通りです。
<TCP singleton_name="tcp"
start_port="7800" end_port="7800"/>
<TCP singleton_name="tcp"
start_port="7800" end_port="7800"/>
TCP 要素固有の属性は次の通りです。
start_portとend_portは、 サーバーがバインドする TCP ポートの範囲を定義します。 サーバーソケットは、start_port以降の最初に利用できるポートへバインドされます。end_portの前に利用可能なポートが見つからない場合 (他のソケットによってポートが使用されている場合など)、 サーバーは例外をスローします。end_portの指定がない場合や、end_portがstart_portよりも低い場合、 ポートの範囲に上限が適用されません。start_portとend_portが同じ場合、 指定されたポートが使用できないとstart_portが失敗するため、 JGroups は指定されたポートの使用を強制されます。 デフォルト値は7800です。0を設定すると、 オペレーティングシステムがポートを選択します (TCCPINGにノードと必要ポートをリストする必要があるため、MPINGやTCPGOSSIPのディスカバリプロトコルを使用する場合にのみ動作します)。- TCP の bind_port は
start_portのエイリアスとして動作します。 内部に設定されるとstart_portを設定します。 - recv_buf_size, send_buf_size は受信と送信のバッファーサイズを定義します。 バッファーのオーバーフローでパケットが破棄される可能性を低減するため、 受信バッファーサイズは大きめにした方がよいでしょう。
- conn_expire_time はトラフィックが受信されていない場合、 ここに指定した時間 (ミリ秒単位) を経過すると reaper によって接続を閉じることができます。
- reaper_interval は reaper を実行する間隔を指定します (ミリ秒単位)。 いずれの値も 0 の場合、 reap は行われません。 いずれかの値が > 0 になる場合、 reap が有効になります。デフォルトでは、reaper_interval が 0 です (つまり、reaper を実行しません)。
- sock_conn_timeout は、ソケット作成に関する最大時間をミリ秒単位で指定します。初めて検索を実行し、ピアがハングする場合は、いつまでも待たずにタイムアウト後に他のメンバに対して ping を実行します。これにより、メンバーがまったく見つからない可能性が少なくなります。デフォルト値は 2000 です。
- use_send_queues は各接続に別の送信キューを使用するかどうかを指定します。これにより、ピアがハングしたときに書き込みブロックが回避されます。デフォルト値は true です。
- external_addr は、他のグループメンバにブロードキャストする外部 IP アドレス (ローカルアドレスと異なる場合) を指定します。これは、NAT (Network Address Translation) とファイアウォールの背後にあるプライベートネットワーク上のノード を使用し、そのノードに外部から見えるアドレス (バインドされるローカルアドレスとは異なります) のみを使用してルーティングできる場合に役に立ちます。したがって、ノードは、引き続きローカルアドレスにバインドできる一方で外部アドレスをブロードキャストするよう設定できます。これにより、ファイアウォール外部のノードはファイアウォール内部のノード (ただし、外部アドレスのもののみ) に引き続きルーティングできるため、TUNNEL プロトコル (つまり、中央ゴシップルーターの要件) を使用する必要がなくなります。external_addr を設定しない場合、ファイアウォール背後のノードはプライベートアドレスをそのアドレスにルーティングできない他のノードにブロードキャストします。
- skip_suspected_members は、ユニキャストメッセージを該当すると思われるメンバに送信するかどうかを指定します。デフォルト値は true です。
- tcp_nodelay は TCP_NODELAY を指定します。デフォルトでは TCP はメッセージに nagle を使用します。つまり、概念的に複数の小さいメッセージは大きいメッセージにまとめられます。同期クラスターメソッド呼び出しを行う場合は、メッセージバンドルを無効にするのに加えて nagle を無効にする必要があります (
enable_bundlingを false に設定します)。nagle を無効にするには、tcp_nodelayを true に設定します。デフォルト値は false です。
注記
27.1.2.3. TUNNEL の設定 リンクのコピーリンクがクリップボードにコピーされました!
TUNNEL プロトコルはメッセージの送信を処理するため外部ルーターを使用します。 外部ルーターは org.jgroups.stack.GossipRouter メインクラスを実行する Java プロセスです。 各ノードはこのルーターに登録する必要があります。 すべてのメッセージがこのルーターに送信されてからその目的地に転送されます。 TUNNEL の方法はファイアウォールの背後にあるノードとの通信を設定するために使用できます。 ノードはファイアウォールを通過して GossipRouter への TCP 接続を確立することができます (80番ポートの使用可)。 ファイアウォールの多くは、 ファイアウォール内部のホストへの TCP 接続を外部ホストが開始するすることを許可しないため、 ルーターによるファイアウォール背後のノードへのメッセージ送信にもこの接続が使用されます。 TUNNEL 設定は、 次のように JGroups <config> 要素内の TUNNEL 要素で定義されます。
<TUNNEL singleton_name="tunnel"
router_port="12001"
router_host="192.168.5.1"/>
<TUNNEL singleton_name="tunnel"
router_port="12001"
router_host="192.168.5.1"/>
TUNNEL 要素内で使用できる属性は以下の通りです。
- router_host は GossipRouter が稼働しているホストを指定します。
- router_port は GossipRouter がリッスンしているポートを指定します。
- reconnect_interval は、 接続が確立できない場合に
TUNNELがGossipRouterへの接続を試行する間隔 (ミリ秒単位) を指定します。 デフォルトは5000です。
注記
TUNNEL に適用されます。
27.1.3. ディスカバリプロトコル リンクのコピーリンクがクリップボードにコピーされました!
<config> エレメント内のサブ要素として設定することもできます。
27.1.3.1. PING リンクのコピーリンクがクリップボードにコピーされました!
<PING timeout="2000"
num_initial_members="3"/>
<PING timeout="2000"
num_initial_members="3"/>
<PING gossip_host="localhost"
gossip_port="1234"
timeout="2000"
num_initial_members="3"/>
<PING gossip_host="localhost"
gossip_port="1234"
timeout="2000"
num_initial_members="3"/>
PING 要素内で使用できる属性は以下の通りです。
- timeout はなんらかの応答を待機する最大ミリ秒数を指定します。デフォルト値は 3000 です。
- num_initial_members は、待機する最大応答数を指定します (タイムアウトが経過していない場合)。デフォルト値は 2 です。
- gossip_host GossipRouter が稼働しているホストを指定します。
- gossip_port GossipRouter がリッスンしているポートを指定します。
- gossip_refresh は GossipRouter からのリースの間隔を指定します (ミリ秒単位)。デフォルト値は 20000 です。
- initial_hosts は、 ディスカバリで ping されるアドレスやポートをコンマで区切った一覧です (例:
host1[12345],host2[23456])。 デフォルトはnullで、 マルチキャストディスカバリが使用されます。initial_hostsを指定した場合、 ウェルノウンホストの一部だけでなく可能なクラスターメンバーすべてをリストに含める必要があります。 すべてをリストしないと、MERGE2クラスタースプリットディスカバリが確実に動作しません。
gossip_host と gossip_port の両方が定義されると、 クラスターは初期のディスカバリに GossipRouter を使用します。 initial_hosts が指定されると、 クラスターはディスカバリにその静的アドレス一覧を ping します。 これ以外は、 クラスターはディスカバリに IP マルチキャスティングを使用します。
注記
timeout ミリ秒が経過した場合、 または num_initial_members 応答が受信された場合です。
27.1.3.2. TCPGOSSIP リンクのコピーリンクがクリップボードにコピーされました!
gossip_host と gossip_port の属性を持つ PING プロトコル設定と同じように動作します。 UDP および TCP 両方のトランスポートプロトコルの上で動作します。 例を示します。
<TCPGOSSIP timeout="2000"
num_initial_members="3"
initial_hosts="192.168.5.1[12000],192.168.0.2[12000]"/>
<TCPGOSSIP timeout="2000"
num_initial_members="3"
initial_hosts="192.168.5.1[12000],192.168.0.2[12000]"/>
TCPGOSSIP 要素内で使用できる属性は以下の通りです。
- timeout はなんらかの応答を待機する最大ミリ秒数を指定します。デフォルト値は 3000 です。
- num_initial_members は、待機する最大応答数を指定します (タイムアウトが経過していない場合)。デフォルト値は 2 です。
- initial_hosts は
GossipRouterが登録するアドレスやポートのコンマで区切りリストしたものです (例:host1[12345],host2[23456])。
27.1.3.3. TCPPING リンクのコピーリンクがクリップボードにコピーされました!
config 要素内の TCPPING 設定要素の例を示します。
<TCPPING timeout="2000"
num_initial_members="3"/
initial_hosts="hosta[2300],hostb[3400],hostc[4500]"
port_range="3">
<TCPPING timeout="2000"
num_initial_members="3"/
initial_hosts="hosta[2300],hostb[3400],hostc[4500]"
port_range="3">
TCPPING 要素で使用できる属性は以下の通りです。
- timeout はなんらかの応答を待機する最大ミリ秒数を指定します。デフォルト値は 3000 です。
- num_initial_members は、待機する最大応答数を指定します (タイムアウトが経過していない場合)。デフォルト値は 2 です。
- initial_hosts は ping を行うアドレスのコンマ区切りリストです (例:
host1[12345],host2[23456])。 - port_range は、 初回のメンバーシップを取得する時に、
initial_hostsパラメータに指定されたポートよりプローブされる連続ポートの数を指定します。 上記のport_rangeとinitial_hostsの値を例とすると、TCPPING層 はhosta[2300]、hosta[2301]、hosta[2302]、hostb[3400]、hostb[3401]、hostb[3402]、hostc[4500]、hostc[4501]、hostc[4502]へ接続しようとします。 この設定オプションにより、 ポートの組み合わせをすべて記述しなくても同じホストの複数のポートへ ping することができます。 TCP プロトコル設定で、end_portがstart_portより大きい場合、 TCPPINGport_rangeがこの差異になるようにし、 許可範囲内でバインドされるポートに関係なくノードが ping されるようにすることが推奨されます。
27.1.3.4. MPING リンクのコピーリンクがクリップボードにコピーされました!
MPING は IP マルチキャストを使用して最初のメンバーシップをディスカバリします。 ネットワーク上でのディスカバリメッセージの送受信をトランスポートプロトコルへ委譲する他とディスカバリプロトコルと違い、 MPING はソケットを開いてマルチキャストディスカバリメッセージを送受信します。 そのため、 すべてのトランスポートに使用できますが、 TCP で最も頻繁に使用されます。 通常、 TCP は可能性があるグループメンバーすべてを明示的にリストする必要がある TCPPING を必要とし、 標準のメッセージトランスポートに TCP が必要で、ディスカバリに UDP マルチキャスティングが許可される場合に使用されます。
MPING 要素で使用できる属性は以下の通りです。
- timeout はなんらかの応答を待機する最大ミリ秒数を指定します。デフォルト値は 3000 です。
- num_initial_members は待機する最大応答数を指定します (タイムアウトが経過しない場合)。デフォルト値は 2 です。
- bind_addr はメッセージの送受信を行うインターフェースを指定します。 デフォルトでは、 JGroups はシステムプロパティ
jgroups.bind_addrの値を使用します。-bコマンドラインスイッチを使用して設定することもできます。 JGroups ソケットのバインドに関する詳細は、 「その他設定の問題」 を参照してください。 - bind_to_all_interfaces は
bind_addrを上書きして multihome ノードにある全インターフェースを使用します。 - mcast_addr, mcast_port, ip_ttl 属性は UDP プロトコル設定にある関連属性と同じものになります。
27.1.4. 障害検出プロトコル リンクのコピーリンクがクリップボードにコピーされました!
<config> 要素内のサブ要素として設定されます。
27.1.4.1. FD リンクのコピーリンクがクリップボードにコピーされました!
FD は「ハートビート」メッセージに基づく障害検出プロトコルです。このプロトコルでは各ノードが定期的に近くのノードに ping する必要があります。近くのノードが応答しないと、呼び出しするノードは SUSPECT メッセージをクラスターに送ります。現在のグループコーディネータは、この疑いのあるノードが実際に停止しているか (VERIFY_SUSPECT) 任意に検証できます。この検証段階の後にまだノードがダウンしている場合、コーディネータがクラスターのビューを更新します。FD 設定の例は次の通りです。
<FD timeout="6000"
max_tries="5"
shun="true"/>
<FD timeout="6000"
max_tries="5"
shun="true"/>
FD 要素で使用できる属性は以下の通りです。
- timeout は are-you-alive メッセージに対する応答を待機する最大ミリ秒数を指定します。デフォルト値は 3000 です。
- max_tries はノードが疑われるまでそのノードから失った are-you-alive メッセージの数を指定します。デフォルト値は 2 です。
- shun は、障害のあるノードが正式にグループに再参加せずにそのグループへのメッセージ送信を不可にするかどうかを指定します。回避されたノードはディスカバリプロセスを通じてクラスターに再参加しなければならなくなります。チャネルが回避されると自動的に再参加やステート移動が発生するよう JGroups を設定することができます (これは JBoss Application Server のデフォルトの動作です)。
注記
27.1.4.2. FD_SOCK リンクのコピーリンクがクリップボードにコピーされました!
FD_SOCK は、 グループメンバ間で作成された TCP ソケットのリングに基づく障害検出プロトコルです。 グループ内の各メンバは近くのメンバに接続し (最後のメンバは最初のメンバに接続します)、 リングを形成します。 ノード B の近くにある ノードA は、 正常に閉じられなかった TCP ソケットを検出した時にノード B を疑い、 ノード B のクラッシュが原因であると想定します (ノードがグループから退出しようとすると、 近くのノードに連絡し、 近くのノードが疑われないようにします)。
FD_SOCK 設定は属性を使用しません。 JGroups <config> 要素に空の FD_SOCK 要素を宣言できます。
<FD_SOCK/>
<FD_SOCK/>
FD_SOCK 要素に使用できる属性は次の通りです。
- bind_addr はメッセージの送受信を行うインターフェースを指定します。 デフォルトでは、 JGroups はシステムプロパティ
jgroups.bind_addrの値を使用します。-bコマンドラインスイッチを使用して設定することもできます。 JGroups ソケットのバインドに関する詳細は、 「その他設定の問題」 を参照してください。
27.1.4.3. VERIFY_SUSPECT リンクのコピーリンクがクリップボードにコピーされました!
<VERIFY_SUSPECT timeout="1500"/>
<VERIFY_SUSPECT timeout="1500"/>
VERIFY_SUSPECT 要素に使用できる属性は次の通りです。
- timeout は、 疑いのあるメンバーの応答を待つ時間を指定します。 この待ち時間を過ぎるとダウンしていると見なされます。
27.1.4.4. FD と FD_SOCK リンクのコピーリンクがクリップボードにコピーされました!
- FD
- 過負荷の状態にあるマシンは、are-you-alive 応答の送信時にパフォーマンスが低下することがあります。
- デバッガ/プロファイラーでサスペンドされたときに、メンバーに問題があるのではと疑いがかけられます。
- タイムアウトを小さくすると、誤検出の可能性が大きくなり、ネットワークトラフィックが増大します。
- タイムアウトが大きいと、クラッシュしたメンバーが一定の時間検出されず、破棄されません。
- FD_SOCK:
- TCP 接続はまだオープンなのでデバッガでサスペンドされても問題ありません。
- 同様の理由により、高ロードも問題とはなりません。
- TCP 接続が中断された場合メンバーに疑いがかけられ、停止しているメンバーは検出されません。
- また、クラッシュしたスイッチは、接続が TCP タイムアウト (2〜20 分。TCP/IP スタック実装によって異なる) になるまで検出されません。
- デフォルトでは、JGroups は KEEP_ALIVE で FD_SOCK ソケットを設定します。これは、TCP が、トラフィックを 2 時間受信していないソケットにハートビートを送信することを意味します。TCP 接続を適切に閉じずにホストがクラッシュすると (または中間スイッチまたはルーターがクラッシュすると)、2 時間 (プラス数分) 後にこれを検出することになります。これは、当然接続をまったく閉じないよりもいいですが (KEEP_ALIVE が無効な場合)、それほど役に立たないことおあります。したがって、最初の解決法は、KEEP_ALIVE のタイムアウト値を小さくすることです。これは、ほとんどのオプションではカーネル全体に対してのみ行えます。したがって、この値を 15 分まで小さくすると、すべての TCP ソケットが影響を受けます。
- 2 つ目の解決法は FD_SOCK と FD を組み合わせることです。FD のタイムアウトは TCP タイムアウトよりもかなり小さくなるよう設定できます。これは 1 つのプロセスごとに個別に設定できます。ソケットが正常に閉じられていない場合は FD_SOCK が疑いがあることを示すメッセージを生成します。ただし、クラッシュしたスイッチまたはホストの場合は、FD によって、ソケットが結果的に閉じられ、疑いがあることを示すメッセージが生成されるようになります。以下に例を示します。
<FD_SOCK/> <FD timeout="6000" max_tries="5" shun="true"/> <VERIFY_SUSPECT timeout="1500"/>
<FD_SOCK/>
<FD timeout="6000" max_tries="5" shun="true"/>
<VERIFY_SUSPECT timeout="1500"/>
FD は 60 秒後 (6000 ミリ秒) 後に近くのメンバを疑います。 この例では、 デバッガのブレークポイントでシステムが停止した場合、 timeout が経過した後にデバッグされたノードが疑われます。
FD と FD_SOCK の組み合わせにより、 安定した障害検出層が提供されます。 このため、 この技術は JBoss Application Server に含まれる JGroups 設定全体で使用されます。
27.1.5. 信頼できる配信プロトコル リンクのコピーリンクがクリップボードにコピーされました!
ACK モードでは、 送信側が受信側からの確認が受信されるまでメッセージを再送します。 NAK モードでは、 受信側がギャップを発見した場合に再送を要求します。
27.1.5.1. UNICAST リンクのコピーリンクがクリップボードにコピーされました!
UNICAST プロトコルはユニキャストメッセージに使用されます。 肯定的な確認を使用し (ACK)、JGroups config 要素のサブ要素として設定されます。 JGroups スタックが TCP トランスポートプロトコルで設定された場合は、 TCP 自体がユニキャストメッセージの FIFO 配信を保証するため UNICAST は必要ありません。 次に、UNICAST プロトコルの設定例を示します。
<UNICAST timeout="300,600,1200,2400,3600"/>
<UNICAST timeout="300,600,1200,2400,3600"/>
UNICAST 要素で設定できる属性は 1 つのみです。
- timeout は、 再送信のタイムアウト (ミリ秒単位) を指定します。 例えば、 タイムアウトが
100,200,400,800の場合、 最初 100 ミリ秒後にACKを受信しなかったら送信元がメッセージを再送信し、 2 回目の再送信を行う前に 200 ミリ秒待ちます。 最初のタイムアウト値を小さくすると、 損失したメッセージの再送信が迅速に行われますが、 実際にメッセージを損失しなかった場合は、 メッセージが複数回送信されます (メッセージは送信されても 、ACKがタイムアウト前に受信されなかった場合)。 UDP データグラムが頻繁に損失しないようネットワークが調整されている場合、 大きな値 (1000,2000,3000) を設定するとパフォーマンスは改善されます。 損失が頻発するネットワークに大きな値を設定すると、 損失したメッセージが再送信されるまで後のメッセージが発信されないため、 パフォーマンスに悪影響を与えます。
27.1.5.2. NAKACK リンクのコピーリンクがクリップボードにコピーされました!
NAKACK プロトコルはマルチキャストメッセージに使用されます。 否定的な確認 (NAK) を使用します。 このプロトコルでは、 各メッセージは連続番号のタグが付けられます。 受信者はこの連続番号を追跡して順序通りにメッセージを配信します。 受信した連続番号でギャップが検出されると、 周期的に損失したメッセージの再送信を送信者に依頼するタスクを受信先が設定します。 損失したメッセージが受信されると、このタスクはキャンセルされます。NAKACK プロトコルは JGroups <config> 要素配下の pbcast.NAKACK サブ要素として設定されます。 設定例は次の通りです。
<pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" retransmit_timeout="300,600,1200,2400,4800" gc_lag="0" discard_delivered_msgs="true"/>
<pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false"
retransmit_timeout="300,600,1200,2400,4800" gc_lag="0"
discard_delivered_msgs="true"/>
pbcast.NAKACK 要素で設定できる属性は以下の通りです。
- retransmit_timeout は、一連のタイムアウト時間 (ミリ秒単位) を指定します。 ここで指定したタイムアウト時間以降に、 損失したメッセージが受信されないと再送信が要求されます。
- use_mcast_xmit は送信者が再送を要求しているノードだけではなくクラスター全体に再送信すべきであるか判断します。 送信者のネットワーク層でパケット落ちが発生する傾向にある場合に便利で、各ノードごとに再送信する必要がありません。
- max_xmit_size は複数メッセージの損失が報告がされた時のバンドル再送信の最大サイズ (バイト単位) を指定します。
- discard_delivered_msgs は受信者ノードで配信されたメッセージを破棄するかを指定します。 デフォルトでは、 ノードが配信されたメッセージを保存するため、 元の送信者がクラッシュあるいはグループを退出してもすべてのノードが損失したメッセージを再送信することができます。ただし、 送信者のみにそのメッセージを再送するよう依頼する場合は、 このオプションを有効にして配信されたメッセージを破棄することができます。
- gc_lag は、 周期的なクリーンアッププロトコル (「分散ガベージコレクション (STABLE)」 参照) がすべてのピアがメッセージを受信したと提示した場合でも、 再送信のためにメモリに保持するメッセージの数を指定します。 デフォルト値は
20です。
27.1.6. グループメンバーシップ (GMS) リンクのコピーリンクがクリップボードにコピーされました!
config 要素配下の pbcast.GMS サブ要素に設定されます。 設定例は次の通りです。
pbcast.GMS 要素で設定できる属性は以下の通りです。
- join_timeout 新しいノードの JOIN 要求が成功するの待つ最長ミリ秒数を指定します。 指定ミリ秒数経過後は再び試行します。
- join_retry_timeout は、 JOIN が失敗した後、 再試行するまでに待機する時間 (ミリ秒単位) を指定します。
- print_local_addr は起動時のノード自体のアドレスを標準出力にダンプするかを指定します。
- shun は、メンバーノードではないクラスタービューを受信した場合にノード自身が shun (切断) を行うかどうかを指定します。
- disable_initial_coord は、最初にチャネルへ接続する際に、ノードがクラスターコーディネーターになることを阻止するか指定します。 現在のコーディネーターがグループから退出した場合、 最初のチャネル接続の後にノードがコーディネーターになることを阻止することはできません。
- view_bundling は、同時に到着した複数の JOIN 要求や LEAVE 要求をまとめて同時に処理し、1 つの新しいビューのみがすべての変更を反映するようにするかを指定します。これは、各要求を別々に処理するよりも効率的です。
27.1.7. フロー制御 (FC) リンクのコピーリンクがクリップボードにコピーされました!
config 要素配下の FC サブ要素に設定されます。 設定例は次の通りです。
<FC max_credits="2000000"
min_threshold="0.10"
ignore_synchronous_response="true"/>
<FC max_credits="2000000"
min_threshold="0.10"
ignore_synchronous_response="true"/>
FC 要素で使用できる属性は以下の通りです。
- max_credits はクレジット (バイト単位) の最大数を指定します。 この値は JVM ヒープサイズより小さくしてください。
- min_credits は、 受信側が送信側にクレジットを送付する前に受け取らなければならない最低バイト数を指定します。
- min_threshold は、
min_creditsを算出するために使用するmax_creditsの割合 (パーセント) を指定します。 この設定はmin_credits属性よりも優先されます。 - ignore_synchronous_response は、 アプリケーションへメッセージを運んだスレッドが、 クレジットをブロックせずに FC より送信メッセージを運び戻すことができるようにするかを指定します。 同期応答とは、 通常これらのメッセージが受信 RPC タイプのメッセージの応答であることを意味しています。 JGroups スレッドが FC のブロックへメッセージを運べないようにすると、 特定のデッドロックを防ぐことができるため、
trueに設定することが推奨されます。
注記
NAKACK が必要となるのです)。
STABLE プロトコルによって管理されます。 詳細は 「分散ガベージコレクション (STABLE)」 を参照してください)。
注記
27.2. 断片化 (FRAG2) リンクのコピーリンクがクリップボードにコピーされました!
config 要素の FRAG2 サブ要素で設定されます。以下に設定例を示します。
<FRAG2 frag_size="60000"/>
<FRAG2 frag_size="60000"/>
- frag_size は、 断片化が発生する前の最大メッセージサイズ (バイト単位) を指定します 。これよりサイズが大きいメッセージは断片化されます。 UDP トランスポートを使用するスタックの値は 64 キロバイト未満 (最大 UDP データグラムサイズ) でなければなりません。 TCP ベースのスタックの値は、 FC プロトコルの
max_creditsの値未満でなければなりません。
注記
FC.max_credits よりも大きいメッセージを送信する場合は、 FC プロトコルがブロックするからです。 したがって、 FRAG2 内の frag_size は常に FC.max_credits よりも小さく設定する必要があります。
27.3. 状態の転送 リンクのコピーリンクがクリップボードにコピーされました!
Config エレメント配下の pbcast.STATE_TRANSFER サブ要素で設定します。 設定できる属性はありません。 次に設定例を示します。
<pbcast.STATE_TRANSFER/>
<pbcast.STATE_TRANSFER/>
27.4. 分散ガベージコレクション (STABLE) リンクのコピーリンクがクリップボードにコピーされました!
config 要素下の pbcast.STABLE サブ要素に設定されます。 設定例は次の通りです。
<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="5000"
max_bytes="400000"/>
<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="5000"
max_bytes="400000"/>
pbcast.STABLE 要素で設定できる属性は以下の通りです。
- desired_avg_gossip はガベージコレクションが実行される間隔を指定します (ミリ秒単位)。 間隔的なガベージコレクションを無効にするには
0を設定します。 - max_bytes はクラスターがガベージコレクション実行を始動させる前に受信する最大バイト数を指定します。 受信バイトを基にしたガベージコレクションを無効にするには
0を設定します。 - stability_delay は、 ガベージコレクション実行の最後にノードが
STABILITYメッセージを送信する前に適用されるランダム遅延の最大時間 (ミリ秒単位) を指定します。 この遅延により、STABLEタスクを同時に実行している別のノードが変更を先に送信できるようにします。max_bytesを併用する場合、 この属性に小さい値を設定する必要があります。
注記
max_bytes 属性を設定します。
27.5. マージ (MERGE2) リンクのコピーリンクがクリップボードにコピーされました!
Config 要素配下の MERGE2 サブ要素で設定します。 以下に例を示します。
<MERGE2 max_interval="10000"
min_interval="2000"/>
<MERGE2 max_interval="10000"
min_interval="2000"/>
MERGE2 要素で使用できる属性は以下の通りです。
- max_interval は MERGE メッセージを送信する前に待機する最大時間 (ミリ秒単位) を指定します。
- min_interval MERGE メッセージを送信する前に待機する最低時間 (ミリ秒単位) を指定します。
min_interval と max_intervalの間の無作為な値を選択します。
注記
注記
MERGE2 を TCPPING とともに使用する場合は、 マージプロセスが適切に実行されるように initial_hosts 属性に再びマージできるすべてのノードを含める必要があります。 そうしないと、 マージプロセスがすべてのサブグループを検出せず、 リストされていないメンバーのみで構成されるサブグループが無視される可能性があります。
27.6. その他設定の問題 リンクのコピーリンクがクリップボードにコピーされました!
27.6.1. JGroups チャネルの特定インターフェースへのバインド リンクのコピーリンクがクリップボードにコピーされました!
jgroups.bind_addr (または廃止された初期の名前である bind.address) が設定されている場合に XML 設定ファイルの bind_addr 要素に設定された値が JGroups によって無視されることを理解することが重要です。このシステムプロパティは XML プロパティよりも優先されます。 JBoss Application Server が -b (または --host スイッチを使用して起動されるとアプリケーションサーバーは jgroups.bind_addr を指定された値に設定します。 -b が指定されないとアプリケーションサーバーはデフォルトでほとんどのサービスを localhost にバインドします。
- JGroups を他のサービスとして同じインターフェースにバインドします。 単純に
-bを使用します。./run.sh -b 192.168.1.100 -c production
./run.sh -b 192.168.1.100 -c productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow - サービス (JBoss Web など) を 1 つのインターフェースにバインドしますが、 JGroups には異なるインターフェースを使用します。
./run.sh -b 10.0.0.100 -Djgroups.bind_addr=192.168.1.100 -c production
./run.sh -b 10.0.0.100 -Djgroups.bind_addr=192.168.1.100 -c productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 特別に設定されたシステムプロパティは-b値よりも優先されます。 これは一般的な使用パターンであり、 一方のネットワークにクライアントトラフィックを割り当て、もう一方のネットワークにクラスター間トラフィックを割り当てます。 - サービス (JBoss Web など) をすべてのインターフェースにバインドします。これは以下のように実行することができます。しかし、これを実行すると JGroups がすべてのインターフェースにバインドしなくなります。代わりに JGroups はマシンのデフォルトのインターフェースにバインドします。JGroups がすべてのインターフェースで送受信するよう指示する方法については、「トランスポートプロトコル」の章を参照してください。
./run.sh -b 0.0.0.0 -c production
./run.sh -b 0.0.0.0 -c productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow - サービス (JBoss Web など) をすべてのインターフェースにバインドしますが、 JGroups インターフェースは指定します。
./run.sh -b 0.0.0.0 -Djgroups.bind_addr=192.168.1.100 -c production
./run.sh -b 0.0.0.0 -Djgroups.bind_addr=192.168.1.100 -c productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでも、 特別に設定したシステムプロパティは-b値よりも優先されます。 - 異なるチャネルに異なるインターフェースを使用します。
./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c production
./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow
jgroups.bind_addr システムプロパティを無視し、代わりに XML で指定された値を使用します。 bind_addr 属性を希望のインターフェースに設定するにはさまざまな XML 設定ファイルを編集する必要があります。
27.6.2. JGroups チャネルの分離 リンクのコピーリンクがクリップボードにコピーされました!
HttpSession レプリケーション、 EJB3 ステートフルセッションBean レプリケーション、 EJB3 エンティティレプリケーション)、 2 つの JBoss Messaging チャネル、 他多くの JBossHA サービスの基礎となる汎用クラスター化サービスである HAPartition などが含まれます。
27.6.2.1. アプリケーションサーバーインスタンス同士を分離 リンクのコピーリンクがクリップボードにコピーされました!
- 異なるクラスターのチャネルが異なるグループ名を使用するようにしてください。 これは、 JBoss の起動に使用されるコマンドライン引数で制御できます。 詳細は、 「グループ名の変更」 を参照してください。
- 異なるクラスターのチャネルが異なるマルチキャストアドレスを使用するようにしてください。 JBoss の起動に使用されるコマンドライン引数を用いると簡単に制御することができます。
- Linux、 Windows、 Solaris、 HP-UX のいずれかで実行していない場合、 各クラスターのチャネルが異なるマルチキャストポートを使用する必要があります。 これは、 異なるグループ名を使用するよりも複雑ですが、 コマンドラインで制御することができます。 「マルチキャストポートの変更」 を参照してください。 サーバーが Linux、 Windows、 Solaris、 HP-UX のいずれかで稼働していれば異なるポートを使用する必要はありません。
27.6.2.2. 同じ AS インスタンスセット上の他のサービスに対してチャネルを分離 リンクのコピーリンクがクリップボードにコピーされました!
clusterName 設定プロパティに固有の値を指定するようにしてください。
27.6.2.2.1. グループ名の変更 リンクのコピーリンクがクリップボードにコピーされました!
-g (または --partition) スイッチを使用するだけで固有のグループ名を作成できます。
./run.sh -g QAPartition -b 192.168.1.100 -c production
./run.sh -g QAPartition -b 192.168.1.100 -c production
jboss.partition.name システムプロパティを設定します。このプロパティをコンポーネントの1つとして利用し、すべての標準的なクラスタリング設定ファイルのグループ名を設定します。例は以下の通りです。
<property name="clusterName">${jboss.partition.name:DefaultPartition}-SFSBCache</property>
<property name="clusterName">${jboss.partition.name:DefaultPartition}-SFSBCache</property>
27.6.2.2.2. マルチキャストアドレスとポートの変更 リンクのコピーリンクがクリップボードにコピーされました!
-u (または --udp) コマンドラインスイッチを使用すると、すべての標準的な AS サービスが開いた JGroups チャネルによって使用されるマルチキャストアドレスを制御できます。
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production
jboss.partition.udpGroup システムプロパティを設定します。これは、JBoss AS の標準プロトコルスタック設定すべてにて参照されます。
<UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" ....
<UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" ....
注記
27.6.2.2.3. マルチキャストポートの変更 リンクのコピーリンクがクリップボードにコピーされました!
-g や -u の値を使うだけではクラスターを分離できないことがあります。 この場合、 異なるクラスターで実行しているチャネルも異なるマルチキャストポートを使用する必要があります。 マルチキャストポートの設定は -g や -u ほど簡単ではありません。 デフォルトでは、production 設定で実行されている JBoss AS インスタンスは、JGroups UDP トランスポートプロトコルの異なるインスタンスを最大で 2 つ使用します。 そのため、 2 つのマルチキャストソケットを開きます。 コマンドラインでシステムプロパティを使用するとソケットが使用するポートを制御できます。例は次の通りです。
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production \\
-Djboss.jgroups.udp.mcast_port=12345 -Djboss.messaging.datachanneludpport=23456
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production \\
-Djboss.jgroups.udp.mcast_port=12345 -Djboss.messaging.datachanneludpport=23456
jboss.messaging.datachanneludpport プロパティは、 JBoss Messaging のDATA チャネルにある MPING プロトコルによって使用されるマルチキャストポートを制御します。 jboss.jgroups.udp.mcast_port プロパティは、 他すべてのクラスター化サービスが共有する UDP トランスポートプロトコルによって使用されるマルチキャストポートを制御します。
$JBOSS_HOME/server/production/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml に含まれる JGroups プロトコルスタック設定には、標準的な JBoss AS ディストリビューションが実際に使用しない他のサンプルプロトコルスタック設定がいくつか含まれています。このような設定もシステムプロパティを使用してマルチキャストポートを設定します。そのため、このようなプロトコルスタック設定の 1 つを使用するよう AS サービスを設定した場合、適切なシステムプロパティを使用してコマンドラインからポートを制御するようにしてください。
注記
java.net.MulticastSocket クラスは異なるオーバーロードしたコンストラクタを提供します。 オペレーティングシステムによっては、 1 つのコンストラクタバリアントを使用すると特定のマルチキャストポートへ提供されたパケットは、 リッスンしているマルチキャストアドレスに関係なくポート上のすべてのリスナに配信されます。 これを、「プロミスキャストラフィック」問題と呼びます 。プロミスキャストラフィック問題が発生するオペレーティングシステムの多くでは (Linux、 Solaris、 HP-UX)、 この問題を回避できる異なるコンストラクタバリアントを JGroups が使用することができます。 しかし、 一部のオペレーティングシステム (Mac OS X) では、 別のコンストラクターバリアントを使用するとマルチキャストが正しく動作しません。 そのため、 このようなオペレーティングシステムでは、 異なるマルチキャストポートを異なるクラスターに設定することが推奨されます。
27.6.2.3. OS UDP の バッファー制限を設定してUDPのパフォーマンスを改善 リンクのコピーリンクがクリップボードにコピーされました!
mcast_recv_buf_size 設定属性と ucast_recv_buf_size 設定属性が使用されますが、 オペレーティングシステムが提供する実際のバッファサイズはオペレーティングシステムレベルの最大値によって制限されます。 このような値は大変小さいことがほとんどです。
| オペレーティングシステム | デフォルトの最大 UDP バッファー (バイト単位) |
|---|---|
| Linux | 131071 |
| Windows | 既知の制限なし |
| Solaris | 262144 |
| FreeBSD、 Darwin | 262144 |
| AIX | 1048576 |
| オペレーティングシステム | コマンド |
|---|---|
| Linux | sysctl -w net.core.rmem_max=26214400 |
| Solaris | ndd -set /dev/udp udp_max_buf 26214400 |
| FreeBSD、 Darwin | sysctl -w kern.ipc.maxsockbuf=26214400 |
| AIX | no -o sb_max=8388608 (AIX は 1 メガバイト、 4 メガバイト、 8 メガバイトのみを許可) |
27.6.3. JGroups のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
27.6.3.1. ノードがクラスターを形成しない リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/production/lib ディレクトリに移動し、McastReceiverTest を起動します。例は次の通りです。
java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555
[lib]$ java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555
McastSenderTestを起動します。
java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555
[lib]$ java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555
-bind_addr 192.168.0.2 を使用します。ここで、 192.168.0.2 はバインドする NIC の IP アドレスです。送信側と受信側の両方でこのパラメーターを使用します。
McastSenderTest ウィンドウに入力すると、 McastReceiverTest ウィンドウに出力が表示されるはずです。 これが不可能な場合は、 送信側で -ttl 32 を使用してください。さらに失敗した場合は、IP マルチキャストを正しく設定する方法についてシステム管理者に問い合わせ、システム管理者に、選択したインターフェースでマルチキャストが動作するよう確認するか、マシンに複数のインターフェースがある場合は、 正しいインターフェースを確認してください。マルチキャストがクラスター内の各マシンで正しく動作している場合は、送信側をあるマシン、受信側を別のマシンに割り当てることによって上記のテストを繰り返してネットワークをテストできます。
27.6.3.2. FD でハートビートが不明な原因 リンクのコピーリンクがクリップボードにコピーされました!
- B または C の CPU 稼働率が T 秒以上 100% である場合。したがって、 C がハートビート ACK を B に送信しても、 B は CPU 稼働率が 100% であるためそれを処理できません。
- B または C がガベージコレクションを実行している場合 (上記と同様)。
- 上記の 2 つのケースの組み合わせ
- ネットワークでパケットが失われる場合。 これは通常、ネットワークに大量のトラフィックが存在し、スイッチがパケットの破棄を開始したときに発生します (通常は最初にブロードキャスト、次に IP マルチキャスト、最後に TCP パケットが失われます)、
- B または C がコールバックを処理している場合。 C がチャネルを介してリモートからのメソッド呼び出しを受信し、その処理に T+1 秒かかるとします。 この時間の間、 C はハートビートを含む他のすべてのメッセージを処理しません。したがって B はハートビート ACK を受信しないため、C を疑うことになります。
第28章 JBoss Cache の設定とデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
28.1. 主な JBoss Cache 設定オプション リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.cache.config.Configuration オブジェクトグラフをビルドするのに JBoss Microcontainer スキーマを使用します。 JBoss Cache は独自のカスタム XML スキーマを持っていますが、 他の内部 Enterprise Application Platform サービスとの整合性を保つため、 標準 JBoss Enterprise Application Platform の CacheManager サービスは JBoss Microcontainer スキーマを使用します。
28.1.1. CacheManager 設定の編集 リンクのコピーリンクがクリップボードにコピーされました!
注記
$JBOSS_HOME/server/PROFILE/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml f ファイルにて設定できます。編集する可能性の高い要素は、 「CacheConfigurationRegistry」 Bean でしょう。この Bean は CacheManager が認識する名前付きの JBC 設定すべてのレジストリを保持しています。このファイルへの編集の多くは、 新しい JBoss Cache 設定の追加や既存設定のプロパティの変更が関係します。
org.jboss.cache.config.Configuration タイプの Java Bean と、 さらに複雑なサブ設定 (キャッシュローティング、 エビクション、 バディレプリケーションなど) に対する子 Java Bean のツリーを作成します。 このような XML の構文分析や Java Bean の作成を JBCに 委譲する代わりに、 Enterprise Application Platform のマイクロコンテナーに直接このタスクを実行してもらいます。 これにより、 マイクロコンテナーは設定 Bean を認識します。 今後の Enterprise Application Platform 5.x リリースでは、 外部管理ツールで JBC 設定を管理できるようにするため便利です。
org.jboss.cache.config.Configuration Java Bean の作成と、 この Bean のプロパティ数の設定を指定します。 ほとんどのプロパティは単純なタイプですが、 buddyReplicationConfig や cacheLoaderConfig などは、 複数タイプの Java Bean を値とします。
28.1.2. キャッシュモード リンクのコピーリンクがクリップボードにコピーされました!
cacheMode 設定属性は、2 つの関連アスペクトを 1 つのプロパティにします。
- 同期 では、 キャッシュインスタンスがピアへメッセージを送信して変更を通知し、ピアが同じ変更を適用したか確認できるまで待機してから返信します。 JTA トランザクションの一部として変更された場合、 トランザクションコミット中の 2 フェーズコミットプロセスの一部として実行されます。 確認が受信されるまでロックは保留されます。 すべてのノードからの確認を待つと遅延が発生しますが、 クラスター周囲の整合性が保たれます。 クラスターのすべてのノードがキャッシュデータにアクセスする可能性があるため 整合性を維持する必要性が高い場合、同期モードが必要となります。
- 非同期では、キャッシュインスタンスがピアにメッセージを送信し変更を通知すると同じ変更を適用したか確認する前に即座に返答します。キャッシュコンテンツを変更したスレッド以外のスレッドが送信メッセージを処理するわけではありません。変更を行うスレッドはクラスターへのメッセージ送信処理を行いますが、処理時間が同期の通信よりも短いだけです。送信を行うキャッシュのみがデータへアクセスし、クラスターメッセージを使い送信ノードに問題があった場合などバックアップコピーを提供するといった、セッション複製などの場合に、非同期モードは最も有用です。非同期のメッセージングは、後に別のノードにフェールオーバーするユーザー要求が期限切れステートになるリスクがありますが、同期モードよりも非同期モードの方がパフォーマンス的に利点が多いため、多くのセッションタイプアプリケーションでこのリスクは受け入れられています。
- ローカルでは、キャッシュインスタンスは全くメッセージを送信しません。 JGroups チャネルもキャッシュによって使用されません。 JBoss Cache にはクラスタリング以外にも多くの便利な機能を持っており、 クラスタで使用されなくても大変有用なキャッシングライブラリとして機能します。また、 クラスター内でもキャッシュされたデータの一部で整合性を保つ必要がありません。 このような場合、 Local モードはパフォーマンスを改善することができます。 JPA/Hibernate クエリ結果セットのキャッシングがこの例となります。 Hibernate の 2 次キャッシングロジックは、 別のメカニズムを使用して 2 次キャッシュの陳腐化したクエリ結果セットを無効にするため、 JBoss Cache はクエリ結果セットキャッシュに対してクラスターの周囲でメッセージを送信する必要はありません。
- レプリケーション では、 送信ノードの新しいステートを反映するため、 他のノードがステートを更新する必要があります。 送信ノードは変更されたステート含める必要があるため、 メッセージの負荷が大きくなります。 他のノードが別の方法でステートを取得できない場合、 レプリケーションが必要となります。
- 無効化 では、 他のノードがローカルステートより変更されたステートを削除する必要があります。 無効化は、 ステート自体ではなく変更されたステートのキャッシュキーのみを送信する必要があるため、 クラスター更新メッセージの負荷を軽減します。 しかし、 削除されたステートを別のソースから取り出すことができる場合のみのオプションとなります。 キャッシュされたステートをデータベースより再読み取りできるため、 クラスター化された JPA/Hibernate エンティティキャッシュに最適なオプションです。
cacheMode 設定属性に対する 5 つの有効な値が形成されます。
- LOCAL はクラスターメッセージが必要ないことを意味します。
- REPL_SYNC は同期されたレプリケーションメッセージが送信されることを意味します。
- REPL_ASYNC は、非同期のレプリケーションメッセージが送信されることを意味します。
- INVALIDATION_SYNC は、 同期された無効化メッセージが送信されることを意味します。
- INVALIDATION_ASYNC は、 非同期の無効化メッセージが送信されることを意味します。
28.1.3. トランザクションの処理 リンクのコピーリンクがクリップボードにコピーされました!
transactionManagerLookupClass 設定属性を設定します。 この属性は、 ローカルトランザクションマネージャーを検索するために JBoss Cache が使用できるクラスの完全修飾クラス名を指定します。 JBoss Enterprise Application Platform 内では、 この属性は次の 2 つの値のいずれかを持ちます。
- org.jboss.cache.transaction.JBossTransactionManagerLookupこの値は、 アプリケーションサーバーで実行されている標準のトランザクションマネージャーを検索します。 JTA トランザクションにキャッシングを参加させたい場合、 デプロイするカスタムキャッシュにこの値を使用します。
- org.jboss.cache.transaction.BatchModeTransactionManagerLookupWeb セッションと EJB SFSB キャッシングに使用されるキャッシュ設定にこの値が使用されます。 JBoss Cache に同梱される、
BatchModeTransactionManagerと呼ばれる疑似のTransactionManagerを指定します。 このトランザクションマネージャーは真の JTAト ランザクションマネージャーではないため、 JBoss Cache 以外には使用しないでください。 JBoss Enterprise Application Platform で使用すると、 要求中に実行されるエンドユーザートランザクションに絡まることなくセッションレプリケーションのユースケースに対して JBoss Cache のトランザクション動作の利点を提供することができます。
28.1.4. 並行アクセス リンクのコピーリンクがクリップボードにコピーされました!
nodeLockingScheme 設定属性と isolationLevel 設定属性によって設定されます。
nodeLockingScheme には次の 3 つを選択できます。
- MVCC (多版型同時実行制御: multi-versioned concurrency control) は、最新のデータベース実装が利用するロッキングスキームで、共有データへの高速で安全な並行アクセスを管理します。JBoss Cache 3.x は MVCC の革新的な実装をデフォルトのロッキングスキームとして使用します。MVCC は並行アクセスに対して次の機能を提供します。並行ライターにデータのバージョン化やコピー化を使用して実現します。 ライターが共有ステートをコピーする間、 リーダーが共有ステートの読み取りを継続し、バージョン ID の値を上げます。 バージョンがまだ有効であることを確認してから (別の並行ライターが先にステートを変更しなかった場合など)、 共有ステートを書き戻します。
- ライターをブロックしないリーダー
- 高速で失敗するライター
JPA/Hibernate エントリキャッシングには MVCC の選択が推奨されます。 - PESSIMISTIC (悲観的) ロッキングでは、 読み取りや書き込みを行う前にスレッドやトランザクションがノード上で排他的ロックか非排他的ロックを取得します。 どちらのロックが取得されるかは、
isolationLevel(下記参照) によって決まりますが、 ほとんどの場合で読み取りには非排他的ロック、 書き込みには排他的ロックが取得されます。 ライターが排他的ロックを完了してリリースするまでリーダースレッドがブロックされるため (書き込みがトランザクションの一部である場合は長期化する可能性があります)、 悲観的ロッキングは MVCC よりかなり多くのオーバヘッドを必要にし、 並行性も低下します。 また、 読み取りが継続することにより、 書き込みの遅延が発生します。JBoss Cache 3.0 で廃止された PESSIMISTIC より MVCC の方が通常は適切ですが、 JBoss Enterprise Application Platform 5.0.0 では PESSIMISTIC がデフォルトとなっています。 これは、 セッションのユースケースには同じキャッシュの場所へアクセスする並行スレッドがなく、 MVCC を使用する利点があまりないからです。 - OPTIMISTIC (楽観的) ロッキングは、 キャッシュにアクセスする各リクエストやトランザクションの「ワークスペース」を作成して PESSIMISTIC の並行性を向上しようとします。リクエストやトランザクションによるデータへのアクセスは (読み取りも含む)、ワークスペースへコピーされるため、 オーバーヘッドが増加します。すべてのデータがバージョン化され、非トランザクションリクエストやトランザクションのコミットが終了すると、ワークスペースのデータバージョンがメインキャッシュと比較され、合致しない場合は例外が発行されます。合致する場合は、ワークスペースへの変更がメインキャッシュに適用されます。OPTIMISTIC ロッキングは廃止されましたが、 後方互換性を維持するために提供されます。 ユーザーは低負荷で同じ利点を持つ MVCC を使用することが推奨されます。
isolationLevel 属性には、 データベーススタイルの分離レベルのセマンティックに対応する READ_COMMITTED と REPEATABLE_READ の 2 つの値が使用できます。 旧バージョンの JBoss Cache は 5 つのデータベース分離レベルすべてをサポートしていました。 サポート対象外の分離レベルを設定すると、 もっとも近いサポート対象レベルにアップブレードまたはダウングレードされます。
28.1.5. JGroups の統合 リンクのコピーリンクがクリップボードにコピーされました!
Channel を使用してグループ通信を処理します。 JBoss Enterprise Application Platform 内部では、 Enterprise Application Platform の JGroups Channel ファクトリサービスをキャッシュの Channel のソースとして使用することが強く推奨されます。 本項では、 チャネルファクトリよりチャネルを取得するようキャッシュを設定する方法について説明します。 別の方法でチャネルを設定したい場合は、 JBoss Cache のドキュメントを参照してください。
jboss-cache-manager-jboss-beans.xml ファイル (「CacheManager サービスによるデプロイメント」 を参照) よりキャッシュを設定する場合は、 次をキャッシュ設定に追加します。 値はプロトコルスタック設定の名前になります。
<property name="multiplexerStack">udp</property>
<property name="multiplexerStack">udp</property>
-jboss-beans.xml ファイルよりデプロイされたキャッシュ
-jboss-beans.xml ファイル (「-jboss-beans.xml ファイルからのデプロイメント」 を参照) よりキャッシュをデプロイする場合は、 チャネルファクトリサービスへの参照を挿入し、 プロトコルスタック設定を指定する必要があります。
-service.xml ファイルよりデプロイされたキャッシュ
-service.xml ファイル (「-service.xml ファイルからのデプロイメント」 を参照) よりデプロイする場合は、 CacheJmxWrapper が MBean のクラスになります。 このクラスは、 MuxChannelFactory MBean 属性を公開します。 この属性へチャネルファクトリサービスの依存関係を挿入し、 MultiplexerStack 属性よりプロトコルスタック名を設定します。
<attribute name="MuxChannelFactory"><inject bean="JChannelFactory"/></attribute> <attribute name="MultiplexerStack">udp</attribute>
<attribute name="MuxChannelFactory"><inject bean="JChannelFactory"/></attribute>
<attribute name="MultiplexerStack">udp</attribute>
28.1.6. エビクション リンクのコピーリンクがクリップボードにコピーされました!
sfsb-cache 設定 (「JBoss Enterprise Application Platform の CacheManager サービス」 参照) にあるエビクション設定を使用してください。 各 Bean の設定に含まれている値を使用して EJB コンテナがエビクションを設定します。
28.1.7. キャッシュローダー リンクのコピーリンクがクリップボードにコピーされました!
passivation フラグの設定によって決まります。 値が true の場合、デ ータがメモリ内キャッシュからエビクトされた時書き込まれるオーバーフロー領域として永続ストアが機能します。
28.1.7.1. Web セッションキャッシュと SFSB キャッシュの CacheLoader 設定 リンクのコピーリンクがクリップボードにコピーされました!
standard-session-cache 設定のキャッシュローダー設定を例にします。
- passivation プロパティは
trueでなければなりません。 - shared プロパティは
falseでなければなりません。 共有の永続ストアにセッションを非活性化しないでください。非活性化すると、 別のノードがセッションをアクティベートした時にセッションが永続ストアより削除され、 以前同じセッションを非活性化した別のノードにあるメモリからも削除されます。 バックアップコピーを紛失します。 - individualCacheLoaderConfigs プロパティはキャッシュローダ設定のリストを許可します。 JBC によって、 キャッシュローダーをチェーンできるようになります。 詳細は JBoss Cache のドキュメントを参照してください。 セッション非活性化のユースケースでは、 単一のキャッシュローダーで十分です。
- キャッシュローダー設定 Bean 上の class 属性は、 キャッシュローダー実装の設定クラスを参照しなければなりません (
org.jboss.cache.loader.FileCacheLoaderConfigまたはorg.jboss.cache.loader.JDBCCacheLoaderConfig)。 使用できる CacheLoader 実装の詳細は JBoss Cache のドキュメントを参照してください。 JDBCCacheLoader を使用したい場合 (FileCacheLoader が使用するファイルシステムではなくデータベースへ永続させるため)、 前述のsharedプロパティに関するコメントを参照してください。 共有データベースは使用しないようにしてください。 最低でもデータベースの共有テーブルは使用しないでください。 クラスタの各ノードは独自の保存場所が必要です。 - FileCacheLoaderConfig の location プロパティは、 非活性化されたセッションが保存されるファイルシステムツリーのルートノードを定義します。 デフォルトでは、 JBoss Enterprise Application Platform 設定の
dataディレクトリに保存されます。 - 非活性化されたセッションが迅速に永続ストアへ書き込まれるようにするため、 async を
falseにしなければなりません。 - キャッシュの開始時に別のノードより転送されるセッションバックアップコピーのセットに非活性化されたセッションが含まれるようにするため、 fetchPersistentState プロパティを
trueにしなければなりません。 - 過去にサーバーがシャットダウンした時に残存した期限切れのセッションデータが現在のデータセットを破損しないようにするため、 purgeOnStartup を
trueにしなければなりません。 - ignoreModifications を
falseにする必要があります。 - マイナーなパフォーマンスの最適化を行うため、 checkCharacterPortability を
falseにしなければなりません。
28.1.8. バディレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
standard-session-cache 設定より、 バディレプリケーション設定のセクションを見てみましょう。
- buddyReplicationEnabled — バディレプリケーションを実行したい場合は
true、 クラスターのすべてのノードでデータをレプリケートする場合はfalseを設定します。falseの場合、バディレプリケーションの他の設定は関係ありません。 - numBuddies — 各ノードがステートをレプリケートするバックアップノードの数です。
- buddyPoolName — クラスター内でノードの論理サブグループ化を有効にします。 可能な場合、 同じバディプール内のノードよりバディが選択されます。
ignoreColocatedBuddies スイッチは、 キャッシュがバディを検索する時に、 可能な場合はキャッシュと同じ物理ホスト上にあるバディを選択しないようにします。 同じマシン上で稼働しているサーバーのみが見つかった場合、 そのサーバーバディとして使用します。
autoDataGravitation、 dataGravitationRemoveOnFind、 dataGravitationSearchBackupTrees の設定は変更しないでください。 これらの変更を変更すると、 セッションレプリケーションが正しく動作しません。
28.2. 独自の JBoss Cache インスタンスをデプロイ リンクのコピーリンクがクリップボードにコピーされました!
28.2.1. CacheManager サービスによるデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
newConfigurations <map> 内に追加します。
28.2.1.1. CacheManager へのアクセス リンクのコピーリンクがクリップボードにコピーされました!
- 依存関係の挿入アプリケーションが設定に JBoss Microcontainer を使用する場合、 サービスに CacheManager を挿入するのが最も簡単な方法となります。
<bean name="MyService" class="com.example.MyService"> <property name="cacheManager"><inject bean="CacheManager"/></property> </bean>
<bean name="MyService" class="com.example.MyService"> <property name="cacheManager"><inject bean="CacheManager"/></property> </bean>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JNDI ルックアップCacheManager を JNDI でルックアップすることもできます。
java:CacheManager以下にバインドされます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - CacheManagerLocatorJBoss Enterprise Application Platform は、 CacheManager へのアクセスに使用されるサービスロケーターオブジェクトも提供します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
28.2.2. -service.xml ファイルからのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
-service.xml ファイルより JBoss Cache インスタンスを MBean サービスとしてデプロイすることもできます。JBoss 4.x と異なる点は、主に mbean 要素にある code 属性の値です。JBoss Enterprise Application Platform 4.x での値は org.jboss.cache.TreeCache でしたが、JBoss Enterprise Application Platform 5.x では org.jboss.cache.jmx.CacheJmxWrapper になりました。例は次の通りです。
CacheJmxWrapper 自体はキャッシュではありません (データの保存などは不可能)。 名前が示す通り、 JMX との統合を処理する org.jboss.cache.Cache 周囲のラッパーになります。 CacheJmxWrapper は、 CacheJmxWrapperMBean MBean インターフェースの Cache 属性を公開します。 キャッシュが必要なサービスは、 この属性よりキャッシュへの参照を取得します。
28.2.3. -jboss-beans.xml ファイルからのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
-jboss-beans.xml ファイルの JBoss Microcontainer スキーマを使用して POJO (Plain Old Java Object) が記述されている場合、 JBoss Enterprise Application Platform 5 は -service.xml で説明した MBean サービスのデプロイメント同様に、 POJO で構成されるサービスをデプロイすることができます。 このようなファイルを作成したら、 直接 deploy ディレクトリにデプロイするか、 ear または sar にパッケージ化することができます。 例は次の通りです。
Configuration オブジェクトの作成になります。 これは、 CacheManager サービスの設定と同じになります (「CacheManager 設定の編集」 参照)。 この例では、 CacheManager サービスをキャッシュファクトリとして使用していないため、 独自のファクトリ Bean を作成し、 キャッシュの作成に使用します (「ExampleCache」Bean)。 そして、「ExampleCache」 が必要とするサービス (架空) へ挿入されます。
RuntimeConfig オブジェクトを見てください。 マイクロコンテナが可視できる TransactionManager や JGroups ChannelFactory などの外部リソースは、 この RuntimeConfig へ依存関係が挿入されます。 この例では、 Enterprise Application Platform における他の配備記述子の一部に、 参照された Bean が既に記述されていることを前提としています。
CacheJmxWrapper はキャッシュの MBean インターフェースを提供する JBoss Cache クラスです。 <annotation> 要素を追加すると、 JBoss Microcontainer @JMX アノテーションを Bean へバインドします。 その結果、 デプロイメントプロセスの一部として JBoss Enterprise Application Platform が Bean を JXM に登録します。
org.jboss.cache.Cache インスタンスは、 cache プロパティにて CacheJmxWrapper より使用できます。 この例は、 キャッシュを「ExampleService」に挿入するための使用方法を表しています。
パート IV. レガシーの EJB サポート リンクのコピーリンクがクリップボードにコピーされました!
第29章 JBoss 上の EJB リンクのコピーリンクがクリップボードにコピーされました!
EJB コンテナー設定とアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
META-INF/jboss.xml 記述子やデフォルトのサーバー全体で対応する standardjboss.xml 記述子を使い設定が可能です。コンテナーアーキテクチャーについて学習していくとともに、この章全体で様々な設定機能を見ていきます。
29.1. EJB クライント側のビュー リンクのコピーリンクがクリップボードにコピーされました!
javax.ejb.EJBHome および javax.ejb.EJBObject を生成します。クライアントは、EJB bean インスタンスを直接参照するわけではなく、bean ホームインターフェースを実装する EJBHome と bean リモートインターフェースを実装する EJBObject を参照します。図29.1「JBoss における EJBHome プロキシの構成」 では、EJB ホームプロキシの構成と EJB デプロイメントとの関係について説明しています。
図29.1 JBoss における EJBHome プロキシの構成
- EJBDeployer (
org.jboss.ejb.EJBDeployer) を呼び出し、EJB JAR をデプロイします。EJBModule(org.jboss.ejb.EJBModule) を作成し、デプロイメントメタデータをカプセル化します。 EJBModuleライフサイクルの作成フェーズで、EJBModuleinvoker-proxy-bindingsメタデータを元に EJB ホームとリモートインターフェースプロキシを管理するEJBProxyFactory(org.jboss.ejb.EJBProxyFactory) を作成します。EJB には複数のプロキシファクトリを関連付けることができ、これから、この定義方法について見ていきます。ProxyFactoryは論理プロキシを構築し、ホームを JNDI にバインドします。論理プロキシは、動的なProxy(java.lang.reflect.Proxy)、プロキシが公開する EJB のホームインターフェース、ClientContainer(org.jboss.proxy.ClientContainer) 形式のProxyHandler(java.lang.reflect.InvocationHandler) 実装、クライアント側のインターセプターで構成されています。EJBProxyFactoryで作成したプロキシは、標準のダイナミックプロキシです。EJBModuleメタデータで定義されているように、EJB ホームとリモートインターフェースをプロキシ化するシリアル可能なオブジェクトです。プロキシは、このプロキシに関連付けられたClientContainerハンドラーを使って、強く型付けされた EJB インターフェースで出されたリクエストを型付けされていない呼び出しに変換します。これは、クライアントをルックアップする EJB ホームインターフェースとして JNDI にバインドされた動的プロキシインスタンスです。クライアントが EJB ホームをルックアップすると、ホームプロキシはClientContainerとそのインターセプターとともに、クライアント VM へ移植されます。動的なプロキシを使うと、他の多くのEJB コンテナーでは必要となる EJB 固有の編集手順を行わなくてもよくなります。- EJB ホームインターフェースは、ejb-jar.xml 記述子で宣言し、EJBModule メタデータから利用可能です。動的プロキシの主なプロパティは、これらのプロキシを公開するインターフェースを実装するために表示されます。これは、Java の強く型付けされたシステムにおいては当てはまります。プロキシは、ホームインターフェースのどれにでもキャスティングでき、またプロキシ化するインターフェースの全詳細を提供するプロキシを反映することができます。
- プロキシは、
ClientContainerハンドラーへのインターフェースのいずれかを使った呼び出しを委譲します。ハンドラーで必要とされる唯一のメソッドは、public Object invoke(Object proxy, Method m, Object[] args) throws Throwableです。EJBProxyFactoryは、ClientContainerを作成し、これをProxyHandlerとして割り当てます。ClientContainerのステータスには、InvocationContext(org.jboss.invocation.InvocationContext)とインターセプターのチェーン (org.jboss.proxy.Interceptor) が含まれています。InvocationContextは以下を含みます。Proxyが関連付けられている EJB コンテナー MBean の JMXObjectName- EJB 向けの
javax.ejb.EJBMetaData - EJB ホームインターフェースの JNDI 名
- トランスポート固有の呼び出し (
org.jboss.invocation.Invoker)
インターセプターチェーンは、EJB ホームとリモートインターフェースの動作を組み立てる機能ユニットで構成されています。これは、jboss.xml記述子についての説明時に見ていきますが、EJB の設定可能なアスペクトで、インターセプターのマークアップがEJBModuleメタデータに含まれています。インターセプター (org.jboss.proxy.Interceptor) は、様々な EJB タイプ、セキュリティ、トランザクション、トランスポートを処理します。独自のインターセプターの追加も可能です。 - プロキシに関連付けられたトランスポート固有の呼び出しは、EJB メソッド呼び出しのトランスポート詳細を処理するサーバー側の分離呼び出しへ紐付けされています。分離呼び出しは、JBoss サーバー側のコンポーネントです。
jboss.xmlclient-interceptors を使って行います。ClientContainer 呼び出しメソッドが呼び出されると、型なしの Invocation (org.jboss.invocation.Invocation) を作成しリクエストをカプセル化します。これがインターセプターチェーンに渡されます。チェーンの最後のインターセプターがトランスポートハンドラーとなり、サーバーへリクエストを送信し、返信を取得する方法を把握しており、トランスポート固有の内容に対応します。
server/production/standardjboss.xml のデフォルトのステートレスセッション bean 設定を見てみましょう。例29.1「Standard Stateless SessionBean 設定からのクライアントインターセプター」 は、 Standard Stateless SessionBean が参照する stateless-rmi-invoker クライアントのインターセプター設定について示しています。
例29.1 Standard Stateless SessionBean 設定からのクライアントインターセプター
META-INF/jboss.xml がない場合に利用される、ステートレスセッション bean 向けのクライアントインターセプター設定です。各クライアントインターセプターが提供する機能は以下の通りです。
- org.jboss.proxy.ejb.HomeInterceptor:
getHomeHandle、getEJBMetaDataを処理し、クライアント VM 内でローカルにてEJBHomeインターフェースのメソッドを削除します。その他のメソッドは、次のインターセプターに伝搬されます。 - org.jboss.proxy.ejb.StatelessSessionInterceptor: クライアント VM 内でローカルにて
EJBObjectインターフェースのtoString、equals、hashCode、getHandle、getEJBHome、isIdenticalメソッドを処理します。その他のメソッドは、次のインターセプターに伝搬されます。 - org.jboss.proxy.SecurityInterceptor: 現在のセキュリティコンテキストをメソッド呼び出しと関連付け、他のインターセプターやサーバーで利用できるようにします。
- org.jboss.proxy.TransactionInterceptor: アクティブなトランザクションと呼び出しメソッドの呼び出しを関連付け、他のインターセプターが利用できるようにします。
- org.jboss.invocation.InvokerInterceptor: メソッド呼び出しのディスパッチをトランスポート固有の呼び出しにカプセル化します。クライアントがサーバーと同じ VM で実行しているか、またこのような場合はオプションで参照渡しへの呼び出しをルーティングするか把握しています。クライアントがサーバー VM の外にある場合、このインターセプターは、この呼び出しを呼び出しコンテキストが紐付いたトランスポート呼び出しに委譲します。例29.1「Standard Stateless SessionBean 設定からのクライアントインターセプター」 設定の場合、これは、
jboss:service=invoker,type=jrmp(JRMPInvokerサービス)が紐付いている呼び出しスタブとなります。org.jboss.invocation.MarshallingInvokerInterceptor: VM 内の呼び出しを最適化しないようにInvokerInterceptorを継承します。これを使いメソッド呼び出しにcall-by-valueセマンティクスを強制的に利用させます。
29.1.1. EJB プロキシ設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
META-INF/jboss.xml 記述子あるいはサーバーのstandardjboss.xml 記述子のいずれかにある invoker-proxy-binding を定義する必要があります。各種デフォルトの EJB コンテナー設定や標準の RMI/JRMP や RMI/IIOP トランスポートプロトコル向けにstandardjboss.xml 記述子に定義されているデフォルトの invoker-proxy-bindings が複数あります。現在のデフォルトプロキシ設定は以下のとおりです。
- entity-rmi-invoker: エンティティ bean 向けの RMI/JRMP 設定
- clustered-entity-rmi-invoker: クラスター化されたエンティティ bean 向けの RMI/JRMP 設定
- stateless-rmi-invoker: ステートレスセッション bean 向けの RMI/JRMP 設定
- clustered-stateless-rmi-invoker: クラスター化されたステートレスセッション bean 向けの RMI/JRMP 設定
- stateful-rmi-invoker: クラスター化されたステートフルセッション bean 向けの RMI/JRMP 設定
- clustered-stateful-rmi-invoker: クラスター化されたステートフルセッション bean 向けの RMI/JRMP 設定
- message-driven-bean: メッセージ駆動型 bean 向けの JMS 呼び出し
- singleton-message-driven-bean: シングルトンメッセージ駆動型 bean 向けの JMS 呼び出し
- message-inflow-driven-bean: メッセージインフロー駆動型 bean の JMS 呼び出し
- jms-message-inflow-driven-bean: 標準のメッセージ駆動型 bean 向けの JMS インフロー呼び出し
- iiop: セッション bean およびエンティティ bean と共に利用する RMI/IIOP
invoker-proxy-bindingを定義する必要がります。プロキシ設定を指定する際の完全な invoker-proxy-binding DTD 部分については、図29.2「invoker-proxy-binding スキーマ」 にあります。
図29.2 invoker-proxy-binding スキーマ
invoker-proxy-binding の子要素は以下の通りです。
- name:
name要素は、invoker-proxy-bindingの一意名を渡します。追加のプロキシバインディングを指定するためにデフォルトのプロキシバインディングと EJB デプロイメントレベルが設定されている場合は、この名前を使い、EJB コンテナー設定からのバインディングを参照します。サーバー側の EJB コンテナー設定を制御するjboss.xml要素をみていただくとこれがどのように行われているかがわかります。 - invoker-mbean:
invoker-mbean要素は、プロキシ呼び出しが紐付けられる分離呼び出し MBean サービスの JMXObjectName文字列を渡します。 - proxy-factory:
proxy-factory要素は、org.jboss.ejb.EJBProxyFactoryインターフェースを実装する必要のあるプロキシファクトリの完全修飾クラス名を指定します。EJBProxyFactoryは、プロキシの設定、プロトコル固有の呼び出し、コンテキストの関連付けといった処理を行います。EJBProxyFactoryインターフェースの現在の JBoss 実装は以下を含みます。- org.jboss.proxy.ejb.ProxyFactory: RMI/JRMP 固有のファクトリ
- org.jboss.proxy.ejb.ProxyFactoryHA: クラスター RMI/JRMP 固有のファクトリ
- org.jboss.ejb.plugins.jms.JMSContainerInvoker: JMS 固有のファクトリ
- org.jboss.proxy.ejb.IORFactory: RMI/IIOP 固有のファクトリ
- proxy-factory-config:
proxy-factory-config要素は、proxy-factory実装の追加情報を指定します。残念ながら、各種要素は構造化されていません。プロキシファクトリの各型を適用しているのは、一部の要素のみとなっています。子要素は、3つの呼び出しプロトコル (RMI/RJMP、RMI/IIOP、JMS) に分類されます。
org.jboss.proxy.ejb.ProxyFactory、org.jboss.proxy.ejb.ProxyFactoryHA については、以下の要素を適用します。
- client-interceptors:
client-interceptorsは、ホームとリモートを定義します。また、オプションで複数の値を持つプロキシインターセプタースタックも定義します。 - web-class-loader: 動的なクラスローディングができるように、web クラスローダーは、プロキシに関連付けられるべき
org.jboss.web.WebClassLoaderインスタンスを定義します。
proxy-factory-config は、RMI でアクセスしたエンティティ bean 用です。
org.jboss.proxy.ejb.IORFactoryについては、以下の要素を適用します。
- web-class-loader: 動的なクラスローディングができるように、web クラスローダーは、プロキシに関連付けられるべき
org.jboss.web.WebClassLoaderインスタンスを定義します。 - poa: 移植可能なオブジェクトアダプターの用途。有効な値は、
per-servantとsharedとなっています。 - register-ejbs-in-jnp-context: EJB が JNDI で登録されるべきか指定するフラグ
- jnp-context: EJB を登録する JNDI コンテキスト
- interface-repository-supported: これは、デプロイ済みの EJB が独自の CORBA インターフェースレポジトリを持つか否かを指定します。
proxy-factory-config です。
org.jboss.ejb.plugins.jms.JMSContainerInvoker については、以下の要素を適用します。
- MinimumSize: これは、MDB 処理の最小プールサイズを指定します。デフォルト値は 1 です。
- MaximumSize: これは、JMS のデスティネーションで許容できる同時 MDB 数の上限を指定します。デフォルト値は、15 です。
- MaxMessages: これは、
javax.jms.QueueConnectionとjavax.jms.TopicConnectionインターフェースのcreateConnectionConsumerメソッドに対するmaxMessagesパラメーター値だけでなく、javax.jms.TopicConnectionのcreateDurableConnectionConsumerメソッドに対するmaxMessagesパラメーター値を指定します。これは1度のサーバーセッションに割り当て可能な最大メッセージ数です。この値は、JMS プロバイダーが対応していると表明していない場合は、デフォルト値から変更すべきではありません。 - KeepAliveMillis: これは、セッションプール内のセッション間のキープアライブ間隔をミリ秒単位で指定します。デフォルト値は、30000 (30 秒) です。
- MDBConfig: MDB JMS 接続動作の設定。要素野中で対応しているものは、以下のとおりです。
- ReconnectIntervalSec: JMS サーバーへの接続回復を試行するまでの待機時間 (秒単位)
- DeliveryActive: MDB が起動時に有効かどうか。デフォルトは True となっています。
- DLQConfig: MDB のデッドレターキューの設定。メッセージの再送が多すぎる場合に利用されます。
- JMSProviderAdapterJNDI:
java:/名前空間の JMS プロバイダーアダプターの JNDI 名。これは、MDB には必須で、org.jboss.jms.jndi.JMSProviderAdapterを実装する必要があります。 - ServerSessionPoolFactoryJNDI: JMS プロバイダーのセッションプールファクトリの
java:/名前空間にあるセッションプールの JNDI 名。これは MDB には必須で、org.jboss.jms.asf.ServerSessionPoolFactoryを実装する必要があります。
standardjboss.xml 記述子から抜粋した、サンプルの proxy-factory-config を提示しています。
例29.2 JMSContainerInvoker proxy-factory-config 例
29.2. EJB サーバー側のビュー リンクのコピーリンクがクリップボードにコピーされました!
29.2.1. 分離呼び出し:トランスポートの仲介 リンクのコピーリンクがクリップボードにコピーされました!
図29.3 トランスポート呼び出しサーバー側のアーキテクチャー
jboss.xml ファイルでは、invoker-proxy-binding-name は、invoker-proxy-binding/name 要素にマッピングします。container-configuration レベルでは、これは、コンテナーにデプロイされる EJB で使うデフォルトの呼び出しを指定します。bean レベルでは、invoker-bindings が1つ以上の呼び出しを指定し、EJB コンテナー MBean とあわせて利用します。
invoker/jndi-name 要素値で指定できます。1つの EJB に対して複数の呼び出しが存在する場合に問題がもう1つあります。それは、EJB が別の bean を呼び出した際に取得したリモートのホームとインターフェースを処理する方法です。クライアントが呼び出しを開始するのに使ったプロキシと、渡されたリモートホームとインターフェースがそれぞれ互換がきくように、このようなインターフェースは、外部の EJB の呼び出しに利用したものと同じ呼び出しを使う必要があります。invoker/ejb-ref 要素を使うと、参照呼び出し型と一致する ejb-ref の参照先 EJB ホームに対し、プロトコルに依存しない ENC ejb-ref からホームプロキシバインディングにマッピングすることができます。
JRMPInvoker MBean の使用しセッション bean 向けに圧縮ソケットを圧縮可能にする例は、testsuite のorg.jboss.test.jrmp パッケージにあります。以下の例では、カスタムの JRMPInvoker 設定と、ステートレスセッション bean へのマッピングについて示しています。
JRMPInvoker がカスタマイズされています。
StatelessSession EJB invoker-bindings 設定は、stateless-compression-invoker を JNDI 名 jrmp-compressed/StatelessSession の配下にバインドされたホームインターフェースと共に利用するように指定しています。stateless-compression-invoker は、先ほど宣言したカスタムの JRMP 呼び出しにリンクされます。
org.jboss.test.hello testsuite パッケージ) は、HttpInvoker を使い、RMI/HTTP プロトコルを利用できるように、ステートレスセッション bean を設定しています。
stateless-http-invoker という名前の invoker-proxy-binding を定義します。これは、分離呼び出しとしてHttpInvoker MBean を使います。jboss:service=invoker,type=http の名前は、http-invoker.sar/META-INF/jboss-service.xml 記述子にあるように、HttpInvoker MBean のデフォルト名で、このサービス記述子の一部については以下に示しています。
HttpInvoker サービス設定で指定している EJBInvokerServlet URL に掲載します。
29.2.2. HA JRMPInvoker - クラスターされた RMI/JRMP トランスポート リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.invocation.jrmp.server.JRMPInvokerHA サービスは、JRMPInvoker の拡張で、クラスター対応の呼び出しとなっています。JRMPInvokerHA は、JRMPInvoker の全属性に完全対応しています。つまり、ポート、インターフェース、ソケットトランスポートのカスタマイズバインディングは、クラスター化された RMI/JRMP でも利用できることになります。HA RMI プロキシのクラスタリングアーキテクチャーと実装に関する追加情報は、JBoss クラスタリングの文書を参照してください。
29.2.3. HA HttpInvoker - クラスターされた RMI/HTTP トランスポート リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml 記述子、あるいは standardjboss.xml 記述子で設定できます。例29.3「HA-RMI/HTTP に対する jboss.xml ステートレスセッション設定」 は、org.jboss.test.hello testsuite パッケージから抜粋したステートレスセッション設定例を示しています。
例29.3 HA-RMI/HTTP に対する jboss.xml ステートレスセッション設定
stateless-httpHA-invoker invoker-proxy-binding は、jboss:service=invoker,type=httpHA 呼び出しサービスを参照しています。このサービスは、以下のように設定することができます。
EJBInvokerHAServlet マッピングです。クラスター全体の HttpInvokerHA インスタンスは、http URL 候補となるものを集め、クライアント側のプロキシが、フェールオーバーおよび/もしくはロードバランシングに利用できるようにしています。
29.3. EJB コンテナー リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb.Container のインスタンスが1つ作成されます。インスタンス化される実際のオブジェクトは、Container のサブクラスで、コンテナーインスタンスの作成は、EJBDeployer MBean が管理します。
29.3.1. EJBDeployer MBean リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb.EJBDeployer MBean は、EJB コンテナーを作成します。デプロイの準備ができた EJB JAR があるとします。EJBDeployer は、EJB のタイプごとに、必要な EJB コンテナーを1つずつ作成し開始します。EJBDeployer の設定可能な属性は以下のとおりです。
- VerifyDeployments: EJB 検証を実行すべきか示す boolean フラッグ。これにより、デプロイメントユニットの EJB が EJB 2.1 仕様に準拠しているか検証します。これを true に設定すると、デプロイメントが有効か確認できるため便利です。
- VerifierVerbose: 検証プロセスから出される検証の失敗/警告をどの程度詳しく出すか制御する boolean。
- StrictVerifier: 厳密な検証を有効化あるいは無効化する boolean。厳密な検証が有効であれば、検証レポートにエラーがない場合にのみ、EJB はデプロイされます。
- CallByValue: 値渡しのセマンティクスをデフォルトで使用すべきであると指示をだす boolean フラグ。
- ValidateDTDs: 宣言した DTD に対して、
ejb-jar.xmlとjboss.xml記述子が有効であることを検証するべきか示す boolean フラグ。これを true にすると、配備記述子が有効であるかを確認できるため便利です。 - MetricsEnabled:
metricsEnabled=true属性で印付けされているコンテナーインターセプターが設定に含めるべきかを示す boolean フラグ。これにより、コンテナーインターセプター設定 (これは On/Off が可)を含むメトリクスタイプのインターセプターを定義できるようになります。 - WebServiceName: Web サービス MBean の JMX ObjectName 文字列。これにより、動的クラスローディングに対応可能にするEJB クラスの動的クラスローディングに対応できるようになります。
- TransactionManagerServiceName: JTA トランザクションマネージャーの JMX ObjectName 文字列。これには、
javax.transaction.TransactionManagerインスタンスを返すTransactionManagerと呼ばれる属性を持たせる必要があります。
EJBDeployer とこれに関連付けられたクラスは、EJB を検証、一意の EJB ごとにコンテナを作成、デプロイメント設定情報でコンテナーを初期化するという、3つの機能を果たします。以下の章で、各機能について説明していきます。
29.3.1.1. EJB デプロイメントの検証 リンクのコピーリンクがクリップボードにコピーされました!
EJBDeployer の VerifyDeployments 属性が true の場合、デプロイヤーはデプロイメントの EJB を検証します。この検証で、EJB が EJB 仕様に準拠しているか確認します。これは、EJB デプロイメントユニットに、必要なホームとリモート、ローカルホーム、ローカルインターフェースが含まれているかの検証も行います。また、これらのインターフェースに表示されるオブジェクトが正しい型で、また実装クラスに必要なメソッドが存在しているかも確認します。EJB 開発者やデプロイヤーは適切な EJB JAR を正しく構築する際に多くの手順を踏む必要があるため間違いを起こしやすいので、便利な動作としてデデフォルトで有効になっています。検証の段階で間違いを突き止め、どこを修正すべきか示すようなエラーを出しデプロイメントが失敗するように試みています。
29.3.1.2. EJB をコンテナーにデプロイ リンクのコピーリンクがクリップボードにコピーされました!
EJBDeployer が行う最も重要な役割は、EJB コンテナーを作成し、EJB をコンテナーにデプロイすることです。デプロイメントフェーズでは、EJB JAR 内で EJB を反復し、ejb-jar.xml および jboss.xml 配備記述子で記述されているように、bean クラスやメタデータを抽出します。EJB JAR の各 EJB に対して、以下の手順を実行します。
- EJB の型 (ステートレス、ステートフル、BMP エンティティ、CMP エンティティ、あるいはメッセージ駆動) に従い、
org.jboss.ejb.Containerのサブクラスを作成します。コンテナーに一意のClassLoaderが割り当てられ、このClassLoaderからローカルリソースをロードすることができます。ClassLoaderの一意性を利用し、標準のjava:compJNDI 名前空間と他の J2EE コンポーネントを分類することができます。 jboss.xmlとstandardjboss.xml記述子を統合したものから取ったコンテナーの設定可能属性をすべて設定します。- コンテナーに設定されているようにコンテナーインターセプターを作成し、追加します。
- アプリケーションオブジェクトとコンテナーを関連付けます。このアプリケーションオブジェクトは、J2EE エンタープライズアプリケーションを表し、複数の EJB および Web コンテキストを含む場合があります。
29.3.1.3. コンテナー設定情報 リンクのコピーリンクがクリップボードにコピーされました!
jboss_4_0.dtd を構成する XML ファイルを使い外部に置いています。コンテナー設定情報に関連する DTD は、図29.4「コンテナー設定関連の jboss_4_0 DTD 要素」 にあります。
container-configuration 要素とそのサブ要素はcontainer-name 要素で提示されているように、コンテナーのタイプ毎にコンテナー構成の設定を指定します。各設定は、デフォルトの呼び出しタイプ、コンテナーインターセプターのマークアップ、インスタンスキャッシュ/プール、そのサイズ、永続マネージャー、セキュリティなどの情報を指定します。これには、JBoss コンテナーアーキテクチャーを詳細まで把握していなければならない情報が大量にあるので、JBoss では EJB の4つのタイプに対する標準設定を同梱しています。この設定ファイルは、standardjboss.xml と呼ばれ、EJB を使う設定ファイルセットの conf ディレクトリに置かれています。以下は、standardjboss.xml からの container-configuration 例となっています。
standardjboss.xml ファイル内で、2つ目は、EJB JAR レベルで指定可能です。EJB JAR META-INF ディレクトリに jboss.xml ファイルを置くことで、standardjboss.xml ファイルのコンテナー設定をオーバーライドするか、あるいは新しく名前をつけたコンテナー設定を指定することも可能です。こうすることで、コンテナーの設定が大幅に柔軟になります。前述したように、コンテナー設定属性はすべて、外部に置かれているため、変更も可能です。知識の豊富な開発者は、インスタンスプールやキャッシュなど、特別なコンテナーコンポーネントを実装し、標準のコンテナー設定と簡単に統合し、特定のアプリケーションや環境で動作の最適化を図ることさえ可能です。
jboss/enterprise-beans/<type>/configuration-name 要素が明示的か暗黙的かにより変わります。configuration-name 要素は、container-configurations/container-configuration へのリンクとなっており、参照 EJB に利用するコンテナー設定はどれかを指定します。これは、configuration-name 要素からcontainer-name 要素をリンクしています。
container-configuration 要素を含めることで、EJB のクラスごとにコンテナー設定を指定することができます。通常、新規コンテナー設定の定義がサポートされていても、完全な定義を行わないようです。jboss.xml レベルの container-configuration は、一般的に、standardjboss.xml 記述子にあるcontainer-configuration の1つあるいは複数の部分をオーバーライドすることで利用しています。これは、既存の standardjboss.xmlcontainer-configuration/container-name 名をcontainer-configuration/extends 属性の値として参照している、container-configuration を指定することで実行できます。以下の例は、Standard Stateless SessionBean 設定の拡張である、新規のSecured Stateless SessionBean 設定を定義してます。
standardjboss.xml 記述子からコンテナー設定を選択します。そのため、実際は、暗黙的な configuration-name 要素が EJB 型ごとに存在し、デフォルトのコンテナー設定へ EJB 型をマッピングしたものは以下の通りになります。
- container-managed persistence entity version 2.0 = Standard CMP 2.x EntityBean
- container-managed persistence entity version 1.1 = Standard CMP EntityBean
- bean-managed persistence entity = Standard BMP EntityBean
- stateless session = Standard Stateless SessionBean
- stateful session = Standard Stateful SessionBean
- message driven = Standard Message Driven Bean
configuration-name を含み、必要なものを備え持った記述子を提供していますが、これは単にスタイルの問題です。
container-configuration 子要素を見ていきます。要素の多くは、インターフェースクラス実装を指定しますが、このインターフェース実装の設定は他の要素から影響を受けるため、設定要素に手を加える前に、org.jboss.metadata.XmlLoadable インターフェースについて理解する必要があります。
XmlLoadable インターフェースは、シンプルなインターフェースでメソッド1つしか含んでいません。インターフェースの定義は以下の通りです。
importXml メソッドに渡されるはずです。以下の章にてコンテナー設定の要素について説明していくため、これについていくつか例を参照できるはずです。
29.3.1.3.1. container-name 要素 リンクのコピーリンクがクリップボードにコピーされました!
container-name 要素は、設定ごとに一意名を指定します。コンテナー設定に関して、EJB のconfiguration-name 要素を container-name の値に設定することで、EJB は特定のコンテナー設定と関連付けられます。
29.3.1.3.2. call-logging 要素 リンクのコピーリンクがクリップボードにコピーされました!
call-logging 要素は、 LogInterceptor はコンテナーへのメソッド呼び出しをログするべきかを指示する値に boolean (true あるいは false) が来るであろうと予測します。これは、細かく設定可能なロギング API を提供する log4j に移行するうえで若干古くなってきています。
29.3.1.3.3. invoker-proxy-binding-name 要素 リンクのコピーリンクがクリップボードにコピーされました!
invoker-proxy-binding-name 要素は、利用するデフォルトの呼び出し名を指定します。bean レベルのinvoker-bindings 指定がない場合、 invoker-proxy-binding-name 要素の値とinvoker-proxy-binding の名前が一致するinvoker-proxy-binding を使い、ホームとリモートのプロキシを作成します。
29.3.1.3.4. sync-on-commit-only 要素 リンクのコピーリンクがクリップボードにコピーされました!
29.3.1.3.5. insert-after-ejb-post-create リンクのコピーリンクがクリップボードにコピーされました!
ejbPostCreate メソッドが呼び出されるまで、新規エンティティ bean に対するデータベースの挿入コマンドが実行されません。こうすることで、デフォルトの挿入後にアップデートを行うことなく、通常の CMP フィールドと CMR フィールドを1回の挿入で設定することができます。結果、関係フィールドに null 値を可能にするための要件を削除できます。
29.3.1.3.6. call-ejb-store-on-clean リンクのコピーリンクがクリップボードにコピーされました!
ejbStore メソッドを呼び出す必要があります。これを false に設定すると、JBoss はダーティオブジェクトに対して ejbStore だけを呼び出すようになります。
29.3.1.3.7. container-interceptors 要素 リンクのコピーリンクがクリップボードにコピーされました!
container-interceptors 要素は、1つ以上のインターセプター要素を指定し、このインターセプター要素はコンテナーにメソッドインターセプターチェーンとして設定されます。インターセプター要素の値は、org.jboss.ejb.Interceptor インターフェース実装の完全修飾名です。コンテナーインターセプターは、 linked-list 構造を形成しており、この構造を使い EJB メソッドの呼び出しを渡します。MBeanServer がコンテナーにメソッド呼び出しを渡すと、チェーンにある最初のインターセプターが呼び出されます。最後のインターセプターは、bean にあるビジネスメソッドを呼び出します。Interceptor インターフェースについては、本章でコンテナープラグインフレームワークについて触れる際に後述します。一般的に、セキュリティ、トランザクション、永続性、スレッドセーフに関する EJB コントラクトはインターセプターから派生しているため、既存の標準 EJB インターセプター設定を変更する際は注意が必要です。
29.3.1.3.8. instance-pool 要素 リンクのコピーリンクがクリップボードにコピーされました!
instance-pool 要素は、org.jboss.ejb.InstancePool インターフェースの完全修飾クラス名を指定し、コンテナー InstancePool として利用します。InstancePool インターフェースについては、本章でコンテナープラグインフレームワークについて触れる際に後述します。
29.3.1.3.9. container-pool-conf 要素 リンクのコピーリンクがクリップボードにコピーされました!
container-pool-conf を InstancePool 実装クラスに渡します。このInstancePool 実装クラスは、XmlLoadable インターフェースが実装された場合にinstance-pool 要素により渡されます。現在の JBoss InstancePool 実装は、図29.5「container-pool-conf 要素の DTD」 で提示している要素へ対応可能にする org.jboss.ejb.plugins.AbstractInstancePool クラスから来ています。
図29.5 container-pool-conf 要素の DTD
- MinimumSize: JBoss では現在
InstancePoolをMinimumSize値にシードしませんが、MinimumSize要素は、プールに保存できるインスタンスの最小数を渡します。 - MaximumSize:
MaximumSizeは、プールインスタンスの上限数を指定します。MaximumSizeのデフォルトの用途は、考えているものと少し違うかもしれません。プールMaximumSizeは、EJB インスタンスの最大利用可能数ですが、同時リクエストの数がMaximumSizeの値を超えた場合、さらにインスタンスを作成することができます。 - strictMaximumSize: EJB の最大並行処理数をプールの
MaximumSizeに制限したい場合、strictMaximumSize要素を true に設定する必要があります。strictMaximumSizeが true の場合、MaximumSizeEJB インスタンスのみがアクティブとなります。MaximumSizeが有効なインスタンスがある場合、インスタンスがプールに開放されるまでその後に続くリクエストはブロックされます。strictMaximumSizeのデフォルト値は、false です。 - strictTimeout: リクエストがインスタンスのプールオブジェクトの待機をブロックする時間は、
strictTimeout要素で制御されます。strictTimeoutは、MaximumSizeが有効なインスタンスがある場合にプールへインスタンスを返すまでの待機時間をミリ秒単位で定義します。0以下の値の場合は待機時間なしとなります。リクエストのインスタンス待機時間がタイムアウトした場合、java.rmi.ServerExceptionが生成され呼び出しが中断されます。これはLongとして解析されるため、最大の許容待機時間は 9,223,372,036,854,775,807 あるいは約 292,471,208 年で、これがデフォルト値となっています。
29.3.1.3.10. instance-cache 要素 リンクのコピーリンクがクリップボードにコピーされました!
instance-cache 要素は、org.jboss.ejb.InstanceCache インターフェース実装の完全修飾名を指定します。この要素は、ID が関連付けられている EJB タイプがエンティティ bean とステートフルセッション bean のみであるため、これらの bean に対してのみ意味をなします。InstanceCache インターフェースについては、コンテナープラグインフレームワークについて本章で後述する際に触れます。
29.3.1.3.11. container-cache-conf 要素 リンクのコピーリンクがクリップボードにコピーされました!
container-cache-conf 要素は、XmlLoadable インターフェースに対応している場合、InstanceCache 実装に渡されます。現在の JBoss InstanceCache 実装はすべて、org.jboss.ejb.plugins.AbstractInstanceCache クラスから来ています。このクラスは、XmlLoadable インターフェースに対応し、インスタンスキャッシュストアとして利用する org.jboss.util.CachePolicy 実装の完全修飾名としてcache-policy 子要素を利用します。cache-policy-conf 子要素は、XmlLoadable インターフェースに対応していれば、CachePolicy 実装に渡されます。対応していない場合は、cache-policy-conf は確認なしに無視されます。
cache-policy-conf 子要素アレイに対応している、standardjboss.xml 設定が利用する CachePolicy の JBoss 実装が2つあります。これらの実装クラスは、 org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy は org.jboss.ejb.plugins.LRUStatefulContextCachePolicy となっています。LRUEnterpriseContextCachePolicy は、エンティティ bean コンテナーに、LRUStatefulContextCachePolicy はステートフルセッション bean コンテナーにより利用されます。このキャッシュポリシーは両方、図29.6「container-cache-conf 要素の DTD」にある以下の cache-policy-conf 子要素に対応しています。
図29.6 container-cache-conf 要素の DTD
- min-capacity: このキャッシュの最小容量を指定します。
- max-capacity: このキャッシュの最大容量を指定しますが、
min-capacityより小さい数値には設定できません。 - overager-period: overager タスクを実行する間隔を秒単位で指定します。overager タスクの目的は、キャッシュに
max-bean-age要素値の一定年齢以上となっている bean が含まれているか確認することです。この基準に合致する bean はすべて非活性化 (passivate) されます。 - max-bean-age: overager プロセスにより非活性化が行われるまで bean がどの程度アクティブでない状態でいられるか上限を指定します。
- resizer-period: resizer タスクを実行する間隔を秒単位で指定します。resizer タスクの目的は、以下の方法で、残り3つの要素値をもとにキャッシュの容量を縮小/拡大します。resizer タスクが実行されると、キャッシュミスの現在の間隔をチェックし、この間隔が
min-cache-miss-periodの値より小さい場合は、cache-load-factorを使い、キャッシュは最大でmax-capacityの値まで拡大されます。キャッシュミスの間隔がmax-cache-miss-period値より小さい場合は、このキャッシュはcache-load-factorを使い縮小されます。 - max-cache-miss-period: キャッシュミスがキャッシュの容量が縮小されたとシグナル送信すべき間隔を指定します。キャッシュが縮小されるまで許容最小の誤り指数と同じになります。
- min-cache-miss-period: キャッシュミスがキャッシュの容量が拡大されたとシグナル送信すべき間隔を指定します。キャッシュが拡大されるまで許容される最大の誤り指数と同じになります。
- cache-load-factor: キャッシュ容量を縮小/拡大する因数を指定します。因数は 1 未満にしてください。キャッシュが縮小される場合、容量が削減されるので bean がキャッシュする容量の現在の割合は cache-load-factor 値と同等になります。 キャッシュが拡大される場合、 新しい容量は
current-capacity * 1/cache-load-factorとして確定されます。実際の拡大因数はキャッシュミス数に基づく内部アルゴリズムに応じて 2 まで上げることができます。キャッシュミス率が高いほど実際の拡大因数は 2 に近くなります。
LRUStatefulContextCachePolicy は残りの子要素にも対応しています。
- remover-period: remover タスクを実行する間隔を秒単位で指定します。 remover タスクは
max-bean-life秒を超える間隔でアクセスされていない非活性化された bean を削除します。このタスクはユーザーにより削除されなかったステートフルセッション bean で非活性化ストアがいっぱいになってしまわないようにします。 - max-bean-life: bean がアクティブでない状態で存在できる最大期間を秒単位で指定します。この期間を超えると、bean は非活性化ストアから削除されます。
org.jboss.ejb.plugins.NoPassivationCachePolicy クラスで、これは単にインスタンスの非活性化を行いません。明示的に削除しない限りインスタンスを破棄することのないインメモリの HashMap 実装を使用します。このクラスはいずれの cache-policy-conf 設定要素もサポートしません。
29.3.1.3.12. persistence-manager 要素 リンクのコピーリンクがクリップボードにコピーされました!
persistence-manager 要素の値は永続管理実装の完全修飾クラス名を指定します。実装タイプは EJB のタイプに依存します。ステートフルセッション bean の場合は org.jboss.ejb.StatefulSessionPersistenceManager インターフェースの実装、そして BMP エンティティ bean の場合は、org.jboss.ejb.EntityPersistenceManager インターフェースの実装でなければならず、CMP エンティティ bean の場合は org.jboss.ejb.EntityPersistenceStore インターフェースの実装でなければなりません。
29.3.1.3.13. web-class-loader 要素 リンクのコピーリンクがクリップボードにコピーされました!
web-class-loader 要素は、WebService MBean と併用する org.jboss.web.WebClassLoader のサブクラスを指定し、デプロイされた ear、EJB JAR および WAR から動的にリソースとクラスをローディングができるようにします。WebClassLoader は Container に関連づけられ、その親として org.jboss.mx.loading.UnifiedClassLoader を持つ必要があります。getURLs() メソッドをオーバーライドし、ローカルのローディングに使用するものとは別のリモートローディング用の URL セットを返します。
WebClassLoader には、サブクラスによりオーバーライドされるはずのメソッドが2つあります。そのメソッドは、getKey() と getBytes() です。2 番目のメソッドはこの実装では空命令で、iiop モジュールで使用されるクラスローダーなどのように、バイトコード生成機能がついたサブクラスにより上書きされるはずです。
WebClassLoader サブクラスは WebClassLoader(ObjectName containerName, UnifiedClassLoader parent) コンストラクターと同じ署名を持つコンストラクターを持っていなければなりません。
29.3.1.3.14. locking-policy 要素 リンクのコピーリンクがクリップボードにコピーされました!
locking-policy 要素は、利用する EJB ロック実装の完全修飾クラス名を渡します。このクラスは org.jboss.ejb.BeanLock インターフェースを実装しなければなりません。現在の JBoss バージョンには次が含まれます。
- org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock: この実装は、公平な FIFO キューでトランザクションロックが開放されるのを待機するスレッドを格納します。トランザクション以外のスレッドもこの待機キューに置かれます。このクラスはキューから次の待機トランザクションをポップしてそのトランザクションに関連づけられ待機中のスレッドにのみ通知します。
QueuedPessimisticEJBLockは標準設定で使用される現在のデフォルトになります。 - org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLockNoADE: デッドロック検出が無効になっている点以外は
QueuedPessimisticEJBLockと同じ動作となります。 - org.jboss.ejb.plugins.lock.SimpleReadWriteEJBLock: このロックにより同時に複数の読み取りロックができるようになります。ライターがこのロックを要求すると、それ以降、トランザクションに読み取りロックをまだ持たない読み取りロックのリクエストは、ライターがすべて終了するまでブロックされます。その後、待機中のリーダーはすべて (再入可能設定/methodLock に従い) 同時に開始します。プロモートするリーダーは、他の待機中のライターよりも先に、書き込みロックをまず試行します。プロモート中のリーダーが存在する場合、矛盾読み取り例外がスローされます。当然、ライターは書き込みロックを得る前にすべての読み取りロックが解放されるのを待たなければなりません。
- org.jboss.ejb.plugins.lock.NoLock: トランザクションコンテナーの設定ごとにインスタンスとともに使用されるアンチロッキングポリシーです。
29.3.1.3.15. commit-option と optiond-refresh-rate 要素 リンクのコピーリンクがクリップボードにコピーされました!
A、B、C、D のいずれかにならなければなりません。
- A: コンテナーがトランザクション間の bean のステータスをキャッシュします。このオプションはコンテナーが永続ストアにアクセスしている唯一のユーザーであると仮定しています。この仮定により、必要な場合に限ってのみコンテナーが永続ストレージからのインメモリステータスを同期できるようになります。見つかった bean で最初のビジネスメソッドが実行される前か、bean が非活性化され別のビジネスメソッドにサービスを提供するため再度アクティブにされた後に、同期が行われます。この動作はビジネスメソッドがトランザクションコンテキスト内で実行されるかどうかには依存しません。
- B: このコンテナーはトランザクション間の bean のステータスをキャッシュします。ただし、オプション
Aとは異なり、このコンテナーは永続ストアへ独占的にアクセスするとの仮定は行いません。したがって、コンテナーは各トランザクション最初にインメモリのステータスを同期します。このため、トランザクションコンテキストの外側で実行しているビジネスメソッド (トランザクション属性が Never、NotSupported または Supports) はキャッシュされた (また無効である可能性がある) bean のステータスにアクセスしますが、トランザクションコンテキスト内で実行しているビジネスメソッドにとってコンテナーが bean をキャッシュしてもあまり役には立ちません。 - C: コンテナーは bean インスタンスをキャッシュしません。インメモリのステータスは各トランザクションの起動時に同期されなければなりません。トランザクションの外側で実行しているビジネスメソッドの場合、同期はいまだ実行されますが
ejbLoadが呼び出し側と同じトランザクションコンテキスト内で実行します。 - D: EJB 仕様には記載されていない JBoss 固有のコミットオプションです。オプション
Aのようにトランザクション間で bean のステータスがキャッシュされる遅延読み取りスキームですが、ステータスが定期的に永続ストアのステータスと再同期されます。再ロードの間隔はデフォルトで 30 秒ですが、optiond-refresh-rate要素を使って設定することができます。
29.3.1.3.16. security-domain 要素 リンクのコピーリンクがクリップボードにコピーされました!
security-domain 要素は org.jboss.security.AuthenticationManager と org.jboss.security.RealmMapping のインターフェースを実装するオブジェクトの JNDI 名を指定します。特定のデプロイメントの EJB すべてが同じ方法でセキュリティーを保てるように、jboss root 要素の下にある security-domain を指定する方がより一般的となります。しかし、各 bean 設定に対してセキュリティドメインを設定することもできます。
29.3.1.3.17. cluster-config リンクのコピーリンクがクリップボードにコピーされました!
cluster-config 要素によりコンテナー設定を使用するすべての EJB に対してクラスター固有の設定を指定することができるようになります。クラスター設定の指定はコンテナー設定レベルか個別の EJB デプロイメントレベルで行うことができます。
- partition-name:
partition-name要素は、クラスタリング情報の交換にコンテナーが使用するorg.jboss.ha.framework.interfaces.HAPartitionインターフェースを検索する場所を指示します。これはHAPartitionがバインドされる場所の完全 JNDI 名ではなく、目的のクラスターを管理しているClusterPartitionMBeanサービスのPartitionName属性に該当するはずです。実際のHAPartitionバインディングの JNDI 名は partition-name 値に/HASessionState/を追加した形式となります。デフォルト値はDefaultPartitionです。 - home-load-balance-policy:
home-load-balance-policy要素はホームプロキシで出された呼び出しの負荷分散に使用する Java クラス名を指示します。このクラスはorg.jboss.ha.framework.interface.LoadBalancePolicyインターフェースを実装しなければなりません。 デフォルトポリシーはorg.jboss.ha.framework.interfaces.RoundRobinになります。 - bean-load-balance-policy:
bean-load-balance-policy要素は bean プロキシで呼び出しの負荷分散に使用する java クラス名を指示します。このクラスはorg.jboss.ha.framework.interface.LoadBalancePolicyインターフェースを実装しなければなりません。エンティティ bean およびステートフルセッション bean の場合デフォルトはorg.jboss.ha.framework.interfaces.FirstAvailavbleで、 ステートレスセッション bean の場合はorg.jboss.ha.framework.interfaces.RoundRobinになります。 - session-state-manager-jndi-name:
session-state-manager-jndi-name要素はクラスター内のステータスセッション管理のバックエンドとしてコンテナーが使用するorg.jboss.ha.framework.interfaces.HASessionStateの名前を指示します。 partition-name 要素とは異なり、HASessionState実装がバインドされる場所の JNDI 名になります。デフォルトの場所は/HASessionState/Defaultです。
29.3.1.3.18. depends 要素 リンクのコピーリンクがクリップボードにコピーされました!
depends 要素はコンテナーまたは EJB が依存するサービスの JMX ObjectName を渡します。その他サービスに対する明示的な依存性を指定すると、必要となるサービス起動後のデプロイメントの順序に依存せずにすみます。
29.3.2. コンテナープラグインのフレームワーク リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb.Container クラスには 4 つのサブクラスがあり、それぞれ特定の bean タイプを実装しています。
- org.jboss.ejb.EntityContainer:
javax.ejb.EntityBeanタイプを処理します。 - org.jboss.ejb.StatelessSessionContainer: ステートレス
javax.ejb.SessionBeanタイプを処理します。 - org.jboss.ejb.StatefulSessionContainer: ステートフル
javax.ejb.SessionBeanタイプを処理します。 - org.jboss.ejb.MessageDrivenContainer:
javax.ejb.MessageDrivenBeanタイプを処理します。
- org.jboss.ejb.ContainerPlugin
- org.jboss.ejb.ContainerInvoker
- org.jboss.ejb.Interceptor
- org.jboss.ejb.InstancePool
- org.jboss.ejb.InstanceCache
- org.jboss.ejb.EntityPersistanceManager
- org.jboss.ejb.EntityPersistanceStore
- org.jboss.ejb.StatefulSessionPersistenceManager
29.3.2.1. org.jboss.ejb.ContainerPlugin リンクのコピーリンクがクリップボードにコピーされました!
ContainerPlugin インターフェースは全コンテナープラグインインターフェースの親インターフェースになります。これによりコールバックができるようになり、コンテナーが各プラグインに対して、プラグインが代わりに作業を行っているコンテナーへのポインターを提供できるようになります。以下に ContainerPlugin インターフェースを示します。
例29.4 org.jboss.ejb.ContainerPlugin インターフェース
29.3.2.2. org.jboss.ejb.Interceptor リンクのコピーリンクがクリップボードにコピーされました!
Interceptor インターフェースにより各 EJB メソッド呼び出しが通過しなければならないメソッドインターセプターのチェーンを構築できるようになります。Interceptor インタフェースは以下に示しています。
例29.5 org.jboss.ejb.Interceptor インターフェース
EJBDeployer によって作成されコンテナインターセプターチェーンに追加されます。最後のインターセプターは EJB bean 実装とやりとりを行うため、デプロイヤーではなく、コンテナー自体によって追加されます。
EnterpriseContext インスタンスに結びつけられていないインターセプターをキャッシュやプールと相互作用するインターセプターより前に配置するために、この順序が存在します。
Interceptor インターフェースの実装はリンクされた一覧のような構造をとり、Invocation オブジェクトはこの構造を通過します。invoker が Invocation を JMX バス経由でコンテナーに渡すと、チェーン内の 1 番目のインターセプターが呼び出されます。最後のインターセプターは bean 上でビジネスメソッドを呼び出します。通常、bean タイプやコンテナー設定によりチェーン内には約 5 つのインターセプターがあります。Interceptor セマンティックは単純なものから複雑なものまで様々です。シンプルなインターセプターの例としては LoggingInterceptor があげられます。また、複雑な例は EntitySynchronizationInterceptor になるでしょう。
TXInterceptor と SecurityInterceptor 間で明確に区別されます。
SecurityInterceptor として失敗します。
29.3.2.3. org.jboss.ejb.InstancePool リンクのコピーリンクがクリップボードにコピーされました!
InstancePool を使用して、いずれの ID にも関連付けられていない EJB インスタンスを管理します。プールは実際には関連付けされていない bean インスタンス群および関連データを集約する org.jboss.ejb.EnterpriseContext オブジェクトのサブクラスを管理します。
例29.6 org.jboss.ejb.InstancePool インターフェース
InstanceCache 実装はプールを使用して有効化を行うための空きインスタンスの獲得を行います。また、プールを利用してインターセプターによって Home インターフェースメソッドに使用するためのインスタンス獲得します (create および finder の呼び出し)。
29.3.2.4. org.jboss.ebj.InstanceCache リンクのコピーリンクがクリップボードにコピーされました!
InstanceCache 実装はアクティブな状態にある EJB インスタンスをすべて処理します。つまり ID が付けられている bean インスタンスということになります。エンティティおよびステートフルセッションの bean のみがメソッド呼び出し間のステータスを持つ bean タイプであるため、これらの bean のみがキャッシュされます。エンティティ bean のキャッシュキーは bean プライマリキーになります。 ステートフルセッション bean のキャッシュキーはセッション ID になります。
例29.7 org.jboss.ejb.InstanceCache インターフェース
InstanceCache はインスタンスの有効化および非活性化も行います。特定の ID を持つインスタンスが要求され、このインスタンスが現在アクティブでない場合、InstanceCache は InstancePool を使用して空きインスタンスを取得し、その後で永続マネージャーがインスタンスを有効にします。同様に、InstanceCache がアクティブなインスタンスの非活性化を行うと決定した場合、永続マネージャーを呼び出しインスタンスの非活性化を行い、そのインスタンスを InstancePool に解放する必要があります。
29.3.2.5. org.jboss.ejb.EntityPersistenceManager リンクのコピーリンクがクリップボードにコピーされました!
EntityPersistenceManager は EntityBeans の永続化を行います。これには次が含まれます。
- ストレージ内で EJB インスタンスを作成
- 特定のプライマリキーの状態を EJB インスタンスにロード
- 特定の EJB インスタンスの状態を格納
- ストレージから EJB インスタンスを削除
- EJB インスタンスの状態を有効化
- EJB インスタンスの状態を非活性化
例29.8 org.jboss.ejb.EntityPersistenceManager インターフェース
29.3.2.6. org.jboss.ejb.EntityPersistenceStore インターフェース リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb.EntityPersistanceStore インターフェースの実装を使用します。デフォルトではこれが org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager で CMP2 永続エンジンのエントリポイントになります。 EntityPersistanceStore インターフェースを以下に示します。
例29.9 org.jboss.ejb.EntityPersistanceStore インターフェース
EntityPersistenceManager インターフェースの BMP デフォルト実装は、 org.jboss.ejb.plugins.BMPPersistenceManager です。 BMP 永続マネージャーはすべての永続ロジックがエンティティ bean 自体の中にあるためかなりシンプルになります。永続マネージャーの唯一の役割はコンテナーのコールバックを行うことです。
29.3.2.7. org.jboss.ejb.StatefulSessionPersistenceManager リンクのコピーリンクがクリップボードにコピーされました!
StatefulSessionPersistenceManager はステートフル SessionBeans の永続性を処理します。これには次のようなものが含まれます。
- ストレージ内でステートフルセッションを作成
- ストレージからステートフルセッションを有効化
- ステートフルセッションをストレージへ非活性化
- ストレージからステートフルセッションを削除
StatefulSessionPersistenceManager インターフェースを以下に示しています。
例29.10 org.jboss.ejb.StatefulSessionPersistenceManager インターフェース
StatefulSessionPersistenceManager インターフェース実装は org.jboss.ejb.plugins.StatefulSessionFilePersistenceManagerになります。その名前の通り、StatefulSessionFilePersistenceManager はファイルシステムを使い、ステートフルセッション bean の永続化を行います。特に永続マネージャーは .ser 拡張子を持つセッション ID と bean 名から成る名前を持つフラットファイル内で bean をシリアル化します。永続マネージャーは有効化をするときに bean の状態を復元し、非活性化を行うときに bean の .ser ファイルからその状態をそれぞれ格納します。
29.4. エンティティ bean のロックとデッドロックの検出 リンクのコピーリンクがクリップボードにコピーされました!
29.4.1. JBoss にロック機能が必要な理由 リンクのコピーリンクがクリップボードにコピーされました!
29.4.2. エンティティ Bean のライフサイクル リンクのコピーリンクがクリップボードにコピーされました!
commit-option タイプに適用されます。このインスタンスのライフサイクルはそれぞれの commit-option とは異なります。
- コミットオプション A の場合、 このインスタンスはキャッシュされトランザクション間で使用されます。
- コミットオプション B の場合は、 このインスタンスはキャッシュされトランザクション間で使用されますが、トランザクションの終わりでダーティと印がつけられます。つまり、新しいトランザクションの開始時に
ejbLoadを呼び出す必要がでてきます。 - コミットオプション C の場合は、 このインスタンスはダーティの印が付けられてキャッシュから解放され、さらにトランザクションの終わりに非活性化用にマークが付けられます。
- コミットオプション D なら、バックグラウンドの更新スレッドが定期的に
ejbLoadをキャッシュ内の古い bean で呼び出します。これ以外、このオプションは Aと同じように動作します。
29.4.3. デフォルトのロッキング動作 リンクのコピーリンクがクリップボードにコピーされました!
- Method Lock: メソッドロックによって特定の Entity Bean 上で呼び出し可能なのは必ず一度に 1 つのスレッド実行のみであるようにします。 これは EJB 仕様では必須となっています。
- Transaction Lock:トランザクションロックを使うと、特定の Entity Bean へのアクセスできるのは必ず一度に 1 トランザクションのみにします。これによりアプリケーションサーバーレベルでのトランザクションの ACID プロパティを確保します。デフォルトでは特定の Entity Bean のアクティブなインスタンスは一度に 1 つとなるため、JBoss はこのインスタンスをダーティな読み込みおよび書き込みから保護しなければなりません。このため、 デフォルトのエンティティ bean ロック機能の動作はそれが完了するまで 1 トランザクション内のエンティティ bean をロックします。 これはトランザクション内のエンティティ bean でなんらかのメソッドが呼び出されると、保持しているトランザクションがコミットを行うまたはロールバックされるまでは他のトランザクションはこの bean へのアクセスできないということになります。
29.4.4. プラグ可能なインターセプターとロックポリシー リンクのコピーリンクがクリップボードにコピーされました!
standardjboss.xml 記述子で定義されるコンテナー設定により定義されることがわかりました。今度は Standard CMP 2.x EntityBean 設定の container-interceptors 定義を見てみることにします。
- EntityLockInterceptor: このインターセプターの役割は呼び出しが続行される前に取得されなければならないロックをすべてスケジュールすることです。このインターセプターは非常に軽量ですべてのロック機能動作をプラグ可能なロックポリシーに委譲します。
- EntityInstanceInterceptor: このインターセプターの役割はキャッシュ内でエンティティ bean を検索する、または新しいエンティティ bean を作成することです。また、このインターセプターは一度にメモリ内に存在する bean のアクティブなインスタンスが必ず 1 つのみであるようにします。
- EntitySynchronizationInterceptor:このインターセプターの役割は基盤となるストレージでキャッシュの状態を同期することです。 EJB 仕様の
ejbLoadおよびejbStoreのセマンティックでこれを行います。トランザクションが存在すると、トランザクションの分離によって引き起こされます。 コールバックを基盤となるトランザクションモニターに JTA インターフェース経由で登録します。トランザクションがない場合、このポリシーは呼び出しから戻ると状態を格納します。その仕様の同期ポリシー A、B、C の他 JBoss 固有のコミットオプション D もここで処理されます。
29.4.5. デッドロック リンクのコピーリンクがクリップボードにコピーされました!
Thread 1 は Bean Aのロック、Thread 2 は Bean B のロックを持っています。しばらくすると、Thread 1 は Thread 2 が Bean B を持っているためそれをロックしてブロックしようとします。同様にして Thread 2 は Thread 1 が A のロックを持っているためそれをロックしてブロックしようとします。この時点で、 両スレッドはデッドロックとなり、 他のスレッドですでにロックされているリソースへのアクセスを待機することになります。
図29.8 デッドロックの定義例
29.4.5.1. デッドロックの検出 リンクのコピーリンクがクリップボードにコピーされました!
| ブロックしている TX | ロックを保持する TX |
|---|---|
| Tx1 | Tx2 |
| Tx3 | Tx4 |
| Tx4 | Tx1 |
ApplicationDeadlockException を送出します。 この例外によりトランザクションのロールバックが行われて、このロールバックによりトランザクションが保持しているすべてのロックが解放されることになります。
29.4.5.2. ApplicationDeadlockException のキャッチ リンクのコピーリンクがクリップボードにコピーされました!
ApplicationDeadlockException が原因で呼び出しが失敗する場合にアプリケーションがトランザクションを再試行できるように独自のアプリケーションを記述してください。 残念ながら、この例外は RemoteException 内の深部に組み込まれるため、独自のキャッチブロックで検索する必要があります。 例えば、
29.4.5.3. ロック情報の表示 リンクのコピーリンクがクリップボードにコピーされました!
EntityLockMonitor MBean サービスにより基本的なロックの統計数値を表示できる他、 トランザクションロック表の状態を出力することもできます。 このモニターを有効にするには、conf/jboss-service.xml 内でその設定のコメントを外します。
<mbean code="org.jboss.monitor.EntityLockMonitor"
name="jboss.monitor:name=EntityLockMonitor"/>
<mbean code="org.jboss.monitor.EntityLockMonitor"
name="jboss.monitor:name=EntityLockMonitor"/>
EntityLockMonitor には設定可能属性はありません。 次のような読み取り専用属性があります。
- MedianWaitTime: ロックの取得にスレッドが待機しなければならなかった全時間の中央値です。
- AverageContenders: ロックを待機しなければならなかった全スレッドの合計 対 競合合計数の比率になります。
- TotalContentions: トランザクションロックを取得するのに待機しなければならなかったスレッドの合計数です。これは、スレッドが別のトランザクションに関連づけられているロックの取得を試行すると発生します。
- MaxContenders: トランザクションロックの取得を待機していたスレッドの最大数です。
- clearMonitor: この操作はすべてのカウンターをゼロにしてロックモニターの状態をリセットします。
- printLockMonitor: この操作は bean の
ejbName、 ロックの待機に要された合計時間、ロックが待たされた回数、ロック待機がタイムアウトとなったトランザクション数を一覧表示する全 EJB ロックの表を出力します。
29.4.6. 詳細設定と最適化 リンクのコピーリンクがクリップボードにコピーされました!
29.4.6.1. 存続期間の短いトランザクション リンクのコピーリンクがクリップボードにコピーされました!
29.4.6.2. アクセスの順序付け リンクのコピーリンクがクリップボードにコピーされました!
29.4.6.3. 読み取り専用 bean リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml 配備記述子内で read-only フラグを使用します。
例29.11 jboss.xml を使いエンティティ bean に読み取り専用と印付ける方法
29.4.6.4. Read-Only メソッドを明示的に定義 リンクのコピーリンクがクリップボードにコピーされました!
jboss.xml 配備記述子内でこうした読み取り専用メソッドを定義することができます。メソッド名にワイルドカードの使用が可能です。次にすべての getter メソッドと anotherReadOnlyMethod を読み取り専用として宣言している例を示します。
例29.12 エンティティ bean メソッドを読み取り専用として定義
29.4.6.5. Instance Per Transaction ポリシー リンクのコピーリンクがクリップボードにコピーされました!
READ_COMMITTED と同じです。必要とされない場合、反復可能読み取りを作成する可能性があります。つまり、トランザクションは古い bean のコピーを持っている可能性があるということです。 次に、この設定オプションは現在、ejbLoad がトランザクションの開始時に発生しなければならないためパフォーマンスの浪費となる可能性があるコミットオプションの B または C が必要になります。ただし、ご使用のアプリケーションが現在いずれにせよこのコミットオプションの B または C を必要とする場合はこの方法を選択すべきでしょう。 JBoss 開発者は現在、 コミットオプション A も許可できる方法を模索しています (このオプションのキャッシュ機能を使用できるようにする)。
Instance Per Transaction CMP 2.x EntityBean と Instance Per Transaction BMP EntityBean という名前のコンテナー設定があり、このコンテナー設定は、このロックポリシーを実装する standardjboss.xml で定義されています。この設定を使用するには、以下に示すように jboss.xml 配備記述子内で bean と併用するようこのコンテナー設定名を参照するだけです。
例29.13 Instance Per Transaction ポリシーの使用例
29.4.7. クラスター内での実行 リンクのコピーリンクがクリップボードにコピーされました!
ejbLoad メソッド内で明示的にその select for update 呼び出しを実装する必要があります。
29.4.8. トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
29.4.8.1. ロッキング動作が機能しない場合 リンクのコピーリンクがクリップボードにコピーされました!
- カスタムの
container-configurationsがある場合はこれらの設定が更新されていることを確認してください。 - equals および hashCode をカスタムまたは総合プライマリキーのクラス群から確実に正しく実装していることを確認してください。
- カスタムのプライマリキーあるいは複雑なプライマリキーのクラスが確実に正しくシリアル化していることを確認してください。よくある誤りのひとつに、プライマリキーがアンマーシャルされるときにメンバー変数の初期化が実行されると思い込んでいる場合があります。
29.4.8.2. IllegalStateException リンクのコピーリンクがクリップボードにコピーされました!
equals と hashCode のいずれかまたは両方が正しく実装されていない、あるいはプライマリキークラスがシリアル化において正しく実装されないことを意味します。
29.4.8.3. ハングとトランザクションタイムアウト リンクのコピーリンクがクリップボードにコピーされました!
29.5. EJB タイマー設定 リンクのコピーリンクがクリップボードにコピーされました!
ejb-deployer.xml ファイル内のいくつかの関連 MBean によって設定されます。主要 MBean は EJBTimerService MBean です。
EJBTimerService には次のような設定可能な属性があります
- RetryPolicy: 再試行ポリシーを実装する MBean の名前です。この MBean は
org.jboss.ejb.txtimer.RetryPolicy interfaceに対応する必要があります。 JBoss はFixedDelayRetryPolicyという実装を1つ提供しており、これについては後ほど説明していきます。 - PersistencePolicy: タイマーイベント保存用の永続方法を実装する MBean の名前です。この MBean は
org.jboss.ejb.txtimer.PersistencePolicyインターフェースに対応しなければなりません。JBoss は NoopPersistencePolicy と DatabasePersistencePolicy の 2 つの実装を提供しており、これについては後ほど説明していきます。 - TimerIdGeneratorClassName: タイマー ID 生成方法を提供するクラスの名前になります。このクラスは
org.jboss.ejb.txtimer.TimerIdGeneratorインタフェースに対応していなければなりません。JBoss はorg.jboss.ejb.txtimer.BigIntegerTimerIdGenerator実装を提供しています。 - TimedObjectInvokerClassname: タイマーメソッド呼び出し方法を提供するクラスの名前になります。このクラスは
org.jboss.ejb.txtimer.TimedObjectInvokerインターフェースを実装していなければなりません。JBoss はorg.jboss.ejb.txtimer.TimedObjectInvokerImpl実装を提供しています。
<mbean code="org.jboss.ejb.txtimer.FixedDelayRetryPolicy"
name="jboss.ejb:service=EJBTimerService,retryPolicy=fixedDelay">
<attribute name="Delay">100</attribute>
</mbean>
<mbean code="org.jboss.ejb.txtimer.FixedDelayRetryPolicy"
name="jboss.ejb:service=EJBTimerService,retryPolicy=fixedDelay">
<attribute name="Delay">100</attribute>
</mbean>
- Delay: 失敗したタイマー実行を再試行するまでの遅延時間 (ミリ秒) になります。 デフォルトの遅延時間は 100 ミリ秒です。
NoopPersistence ポリシーを使用することができます。この MBean はデフォルトではコメントアウトされていますが、有効にすると次のようになります。
<mbean code="org.jboss.ejb.txtimer.NoopPersistencePolicy"
name="jboss.ejb:service=EJBTimerService,persistencePolicy=noop"/>
<mbean code="org.jboss.ejb.txtimer.NoopPersistencePolicy"
name="jboss.ejb:service=EJBTimerService,persistencePolicy=noop"/>
DatabasePersitencePolicy MBean を使用してください。
- DataSource: タイマーデータの書き込み先となる DataSource の MBean です。
- DatabasePersistencePlugin: 永続方法を実装するクラスの名前になります。これは
org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePluginになるはずです。
第30章 CMP エンジン リンクのコピーリンクがクリップボードにコピーされました!
30.1. サンプルコード リンクのコピーリンクがクリップボードにコピーされました!
図30.1 犯罪ポータルのクラス例
src/main/org/jboss/cmp2 にあります。サンプルコードをビルドするには、以下のようにして Ant を実行します。
ant -Dchap=cmp2 config
[examples]$ ant -Dchap=cmp2 config
30.1.1. CMP デバッグロギングの有効化 リンクのコピーリンクがクリップボードにコピーされました!
log4j.xml ファイルに追加します。
<category name="org.jboss.ejb.plugins.cmp">
<priority value="DEBUG"/>
</category>
<category name="org.jboss.ejb.plugins.cmp">
<priority value="DEBUG"/>
</category>
CONSOLE アペンダーのしきい値を下げ、コンソールにデバッグレベルのメッセージが記録されるように設定します。 次の変更も log4j.xml ファイルに適用する必要があります。
org.jboss.ejb.plugins.cmp カテゴリでカスタムの TRACE レベル優先度を有効にする必要があります。
<category name="org.jboss.ejb.plugins.cmp">
<priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>
<category name="org.jboss.ejb.plugins.cmp">
<priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>
30.1.2. サンプルの実行 リンクのコピーリンクがクリップボードにコピーされました!
ant -Dchap=cmp2 -Dex=test run-example
[examples]$ ant -Dchap=cmp2 -Dex=test run-example
ant -Dchap=cmp2 -Dex=readahead run-example
[examples]$ ant -Dchap=cmp2 -Dex=readahead run-example
30.2. jbosscmp-jdbc の構造 リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml 記述子を使って JBoss エンジンの動作を制御します。サーバー設定ファイルセットにある conf/standardjbosscmp-jdbc.xml 記述子でグローバルに行うか、META-INF/jbosscmp-jdbc.xml 記述子で EJB JAR デプロイメントごとに実行することができます。
jbosscmp-jdbc.xml 記述子の DTD は JBOSS_DIST/docs/dtd/jbosscmp-jdbc_4_0.dtd にあります。この DTD 用のパブリック doctype:
<!DOCTYPE jbosscmp-jdbc PUBLIC
"-//JBoss//DTD JBOSSCMP-JDBC 4.0//EN"
"http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_4_0.dtd">
<!DOCTYPE jbosscmp-jdbc PUBLIC
"-//JBoss//DTD JBOSSCMP-JDBC 4.0//EN"
"http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_4_0.dtd">
図30.2 jbosscmp-jdbc コンテンツモデル
- defaults: デフォルトセクションではエンティティ bean を制御する動作のデフォルト動作/設定を指定できます。このセクションを使用するとエンティティ bean セクションにて共通動作に必要とされる情報量を低減します。デフォルトコンテンツについては 「デフォルト」 を 参照してください。
- enterprise-beans:
enterprise-beans要素はejb-jar.xmlenterprise-beans記述子で定義されるエンティティ bean のカスタマイズが可能です。これについては「エンティティ Bean」で詳しく説明しています。 - relationships:
relationships要素は、エンティティの関係に関するローディング動作やテーブルのカスタマイズを行うことができます。これについては 「コンテナー管理リレーション」で詳しく説明しています。 - dependent-value-classes:
dependent-value-classes要素では 依存値クラス (DVC: Dependent value class) のテーブルへのマッピングをカスタマイズすることができます。依存値クラスについては 「依存値クラス(DVC: Dependent Value Class)」 (DVC) で詳しく説明しています。 - type-mappings:
type-mappings要素は、 SQL テンプレートや関数マッピングとともに、データベース用に Java から SQL の型マッピングを定義します。これについては 「データソースのカスタマイズ」で詳しく説明しています。 - entity-commands:
entity-commands要素は、永続ストアでのエンティティインスタンスの作成方法を把握しているエンティティ作成コマンドインスタンスの定義ができます。これについては 「エンティティコマンドおよびプライマリキー生成」で詳しく説明しています。 - user-type-mappings:
user-type-mappings要素はマッパークラスを使った列へのユーザータイプのマッピングを定義します。マッパーとはいわば仲介役です。格納時、ユーザータイプのインスタンスを取得してカラム値に変換します。ロードする場合は、カラム値を取得してそれをユーザータイプのインスタンスに変換します。ユーザータイプのマッピングについては 「ユーザータイプマッピング」で詳しく説明しています。 - reserved-words:
reserved-words要素はテーブル生成時にエスケープすべき1つ以上の予約語を定義します。各予約語は word 要素の内容として指定されます。
30.3. エンティティ Bean リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml 配備記述子のみです。実際の bean クラスの名前は GangsterBean ですが、このエンティティをここでは GangsterEJB と呼んでいます。
2.x を指定しているので注意してください。抽象スキーマ名は gangster に設定しました。「クエリ」で EJB-QL クエリーを確認する際にこれが重要となります。
30.3.1. エンティティマッピング リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml ファイル内の entity 要素で宣言されます。このファイルは EJB JAR の META-INF ディレクトリに配置され、CMP マッピング設定用の全オプション設定情報を含んでいます。各 bean の entity 要素はトップレベルの jbosscmp-jdbc 要素の配下にある enterprise-beans 要素内にグループ化されます。スタブアウトしたエンティティ設定を以下に示します。
ejb-name 要素は、ejb-jar.xml ファイルにあるものとエンティティの仕様を適合させる必要があります。その要素の残りはグローバルか、又はアプリケーションレベルの CMP デフォルトと bean に特有の CMP マッピング詳細を上書きします。アプリケーションデフォルトは jbosscmp-jdbc.xml ファイルの defaults セクションから出るものであり、グローバルデフォルトは現在のサーバー設定ファイルセットの conf ディレクトリにある defaults セクションから出るものです。 defaults セクションについては、「デフォルト」 で説明があります。図30.3「エンティティ要素のコンテンツモデル」 は完全な entity コンテンツモデルを示しています。
図30.3 エンティティ要素のコンテンツモデル
- ejb-name: この必須要素は、この設定が適用される EJB 名です。この要素は
ejb-jar.xmlファイル内のエンティティのejb-nameと一致しなければなりません。 - datasource: この任意要素はデータソースの検索に使用される
jndi-nameになります。エンティティまたは関係テーブルで使用されるデータベース接続はすべてデータソースから取得されます。エンティティに対して異なるデータソースを指定すると、finder および ejbSelect がクエリできるドメインを大幅に制約することになるため推奨しません。デフォルトセクションでオーバーライドされない限りjava:/DefaultDSがデフォルトです。 - datasource-mapping: この任意要素は
type-mapping名を指定し、 Java タイプが SQL タイプにマッピングされる方法、および EJB-QL 関数がデータベース固有の関数にマッピングされる方法を指定します。タイプのマッピングについては 「マッピング」で説明します。デフォルトセクションでオーバーライドされない限りHypersonicSQLがデフォルトです。 - create-table: この任意要素が true の場合 JBoss はエンティティに対してテーブルの作成を試行しなければならないことを指定します。アプリケーションがデプロイされると、JBoss はテーブル作成の前にすでにテーブルが存在しているかどうか確認します。テーブルが見つかった場合、ログが記録されるだけでテーブルは作成されません。このオプションは、テーブルの構成が頻繁に変更する開発初期段階で非常に役立ちます。デフォルトセクションでオーバーライドされない限り、デフォルトは false です。
- alter-table: スキーマの自動作成に
create-tableが使用される場合、alter-tableを使ってエンティティ bean に対する変更を反映しスキーマを最新状態に保つことができます。Alter table は次のような特定のタスクを実行します。- 新しいフィールドが作成されます。
- 使用されなくなったフィールドが削除されます。
- 宣言されている長さより短い文字列フィールドは宣言されている長さまで延長されます(すべてのデータベースでサポートされているわけではありません)。
- remove-table: この任意の要素が true の場合、JBoss は各エンティティおよび関連性をマッピングした各関係テーブルに対してテーブルのドロップを試行します。アプリケーションがアンデプロイされると、JBoss はこのテーブルをドロップを試行します。このオプションは、テーブルの構成が頻繁に変更される開発初期段階で非常に役立ちます。デフォルトセクションでオーバーライドされない限り、デフォルトは false です。
- post-table-create: この任意要素はデータベーステーブルの作成直後に実行されるべき任意の SQL ステートメントを指定します。このコマンドは
create-tableが true でテーブルが以前に存在しない場合にのみ実行されます。 - read-only: この任意の要素が true の場合、 bean プロバイダーはいずれのフィールドの値を変更することも許可されないことを指定します。読み取り専用のフィールドはデータベースに格納もしくは挿入されません。プライマリキーフィールドが読み取り専用である場合、create メソッドが
CreateExceptionを送出します。set アクセッサーが読み取り専用フィールドで呼び出しされると、EJBExceptionをスローします。読み取り専用フィールドは最後の更新などデータベースのトリガーで入力されるフィールドに便利です。read-onlyオプションはcmp-fieldごとにオーバーライドが可能です。詳しくは 「Read-only フィールド」 で説明します。defaultsセクションでオーバーライドされない限り、デフォルトは false です。 - read-time-out: この任意の要素は読み取り専用フィールドでの読み取りが有効である期間をミリ秒単位で表します。値が 0 の場合、常にトランザクション開始時に値が再ロードされることになり、値が -1 の場合は値がタイムアウトすることがないという意味になります。このオプションも
cmp-fieldごとにオーバーライドが可能です。read-onlyが false の場合、この値は無視されます。デフォルトはdefaultsセクションでオーバーライドされない限り -1 です。 - row-locking: この任意の要素が true の場合、sJBoss はトランザクションでロードされたすべての列をロックすることを指定します。ほとんどのデータベースがエンティティをロードする際に
SELECT FOR UPDATE構文を使ってこれを実装していますが、実際の構文はこのエンティティで使用されるデータソースマッピング内のrow-locking-templateで確定されます。defaultsセクションでオーバーライドされない限り、デフォルトは false です。 - pk-constraint: この任意の要素が true の場合、 JBoss はテーブル作成時にプライマリキー制約を追加することを指定します。defaults セクションでオーバーライドされない限り、デフォルトは true です。
- fetch-size: この任意の要素は基礎となるデータストアへの 1 往復で読み込むエンティティ数を指定します。defaults セクションでオーバーライドされない限り、デフォルトは 0 です。
- list-cache-max: この任意の要素はこのエンティティで追跡可能な read-list 数を指定します。このオプションについては
on-loadで説明します。defaults セクションでオーバーライドされない限り、デフォルトは 1000 です。 - clean-read-ahead-on-load: 先行読み込み (read ahead) キャッシュからエンティティがロードされる場合、 JBoss は先行読み込みキャッシュから使用されるデータを削除することができます。デフォルトは
falseになります。 - table-name: この任意の要素はこのエンティティ用のデータを保持するテーブル名になります。各エンティティインスタンスはこのテーブルの 1 列内に格納されます。デフォルトは
ejb-nameになります。 - cmp-field: この任意の要素で
ejb-jar.xmlcmp-fieldを永続ストア上でマッピングする方法を定義することができます。このオプションについては 「CMP フィールド」で説明します。 - load-groups: この任意の要素はフィールドのロードグループ化を宣言する CMP フィールドの 1つ以上の グループ化を指定します。このオプションについては 「Load Groups」で説明します。
- eager-load-groups: このオプションのエレメントは eager load group として 1 つ以上のロードグループ化を定義します。このオプションについては 「一括読み込みプロセス」で説明します。
- lazy-load-groups: この任意の要素は lazy load group として 1 つ以上のロードグループ化を定義します。これについては 「遅延ローディングプロセス」で説明します。
- query: この任意の要素は finder と selector の定義を指定します。これについては 「クエリ」で説明します。
- unknown-pk: この任意の要素により
java.lang.Objectの未知のプライマリキータイプを永続ストアにマッピングする方法を定義することができます。 - entity-command: この任意の要素によりエンティティ作成コマンドインスタンスを定義することができます。一般的にこれを使いカスタムのコマンドインスタンスを定義することで、プライマリキー生成を可能にします。これについては 「エンティティコマンドおよびプライマリキー生成」 で詳しく説明しています。
- optimistic-locking: この任意の要素は楽観的なロッキングに対して使用するストラテジーを定義します。これについては 「楽観的ロッキング」で説明します。
- audit: この任意の要素は監査予定の CMP フィールドを定義します。詳しくは 「エンティティアクセスの監査」で説明します。
30.4. CMP フィールド リンクのコピーリンクがクリップボードにコピーされました!
name CMP フィールドへアクセスができるように getName() と setName() メソッドがあります。本項では、これらの宣言 CMP フィールドの設定方法、永続性や動作の制御方法について検証します。
30.4.1. CMP フィールド宣言 リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml ファイル内で始まります。たとえば、 gangster bean では name、nickName、badness が ejb-jar.xml ファイルで次のように宣言されます。
30.4.2. CMP フィールドのカラムマッピング リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml ファイルで行います。この構成は配下に cmp-field 要素と追加設定詳細を持つエンティティ element がある ejb-jar.xml に似ています。
jbosscmp-jdbc.xml の cmp-field 要素の完全コンテンツモデルを以下に示します。
図30.4 JBoss エンティティ要素のコンテンツモデル
- field-name: この必須の要素は設定中の
cmp-field名です。ejb-jar.xmlファイル内でこのエンティティ用に宣言されるcmp-fieldのfield-name要素と一致しなければなりません。 - read-only: これは対象となるフィールドが読み取り専用であることを宣言するものです。このフィールドは JBoss ではデータベースに書き込まれません。読み取り専用フィールドについては 「Read-only フィールド」で説明します。
- read-only-timeout: read-only フィールドの値が有効と判断した期間をミリ秒単位で表します。
- column-name: この任意の要素は
cmp-fieldのマッピング先となるカラム名です。field-name値を使用するのがデフォルトです。 - not-null: この任意の要素は、このエンティティ用の表の自動作成時に JBoss が NOT NULL をカラム宣言の末尾に追加すべきことを示します。プライマリキーフィールド とプリミティブ用のデフォルト は not null です。
- jdbc-type: JDBC で準備されたステートメント内にパラメーターを設定するか、JDBC 結果セットからデータをロードする場合に使用される JDBC タイプです。有効なタイプは
java.sql.Typesで定義されます。sql-typeが指定された場合にのみ必要です。デフォルトの JDBC タイプはdatasourcemapping内のデータベースタイプに基づきます。 - sql-type: このフィールドの create テーブルステートメントで使用される SQL タイプです。有効な SQL タイプはデータベースベンダーによって異なります。
jdbc-typeが指定された場合にのみ必要です。デフォルトの SQL タイプはdatasourcemapping内のデータベースタイプによって決定されます。 - property: この任意の要素により dependent value class CMP フィールドのプロパティが永続ストアにどのようにマッピングされるか定義することができるようになります。これについては 「依存値クラス(DVC: Dependent Value Class)」で詳しく説明します。
- auto-increment: この任意のフィールドがあると、データベース層ごとに自動的に増分されることを示します。これはフィールドを生成されたカラムやかい部で操作されたカラムにマッピングするために使用します。
- dbindex: この任意のフィールドがあると、サーバーはデータベース内の該当するカラムにインデックスを作成することを示します。このインデックス名は fieldname_index になります。
- check-dirty-after-get: この値はプリミティブタイプとそのベーシック java.lang 不変ラッパー(
Integer、Stringなど)に false をデフォルト設定します。不変となる可能性があるオブジェクトに対しては、 JBoss は get オペレーションのあとダーティの可能性ありとしてそのフィールドをマークします。オブジェクトでのダーティチェックにおける金額的な負担が大きすぎる場合は、check-dirty-after-getを false に設定して最適化することができます。 - state-factory: このフィールドにダーティチェックを行うことができる状態ファクトリオブジェクトのクラス名を指定します。状態ファクトリクラスは
CMPFieldStateFactoryインターフェースを実装する必要があります。
30.4.3. Read-only フィールド リンクのコピーリンクがクリップボードにコピーされました!
cmp-field 宣言で read-only と read-time-out の要素を設定することで読み取り専用 CMP フィールドを有効にします。これらの要素はエンティティレベルでの動作と同じです。フィールドが読み取り専用の場合、INSERT または UPDATE のステートメントで使用されることはありません。プライマリキーフィールドが read-only の場合、 create メソッド は CreateException を送出します。set アクセッサーが読み取り専用フィールドで呼びだされると、EJBExceptionをスローします。読み取り専用フィールドは最後の更新などデータベーストリガーで入力されるフィールドに便利です。読み取り専用 CMP フィールド宣言のサンプルを次に示します。
30.4.4. エンティティアクセスの監査 リンクのコピーリンクがクリップボードにコピーされました!
audit 要素により、エンティティ bean とアクセス権限の監査の方法を指定できます。これが確立した呼び出し ID となるように、セキュリティドメイン下で エンティティ bean にアクセスする場合にのみ可能となります。audit 要素の コンテンツモデルは図30.5「jbosscmp-jdbc.xml 監査要素のコンテンツモデル」 でご覧になれます。
図30.5 jbosscmp-jdbc.xml 監査要素のコンテンツモデル
- created-by: この任意の要素はエンティティを作成した呼び出し側が指定の
column-nameまたは cmpfield-nameのいずれかに保存されるよう指定します。 - created-time: この任意の要素はエンティティの作成時間が指定の
column-nameまたは cmpfield-nameのいずれかに保存されるよう指定します。 - updated-by: この任意の要素はエンティティを最後に変更した呼び出し側が指定の
column-nameあるいは CMPfield-nameのいずれかに保存されるよう指示します。 - updated-time: この任意の要素はエンティティの最終更新時間が指定の
column-nameまたは CMPfield-nameのいずれかに保存されるよう指定します。
field-name が与えられる場合は、アクセスされたエンティティ bean の指定 CMP フィールドに、該当する監査情報が格納されるようになっています。エンティティ上に該当する CMP フィールドが宣言される必要はありません。一致するフィールド名がある場合は、 該当する CMP フィールドの抽象 getter と setter を使ってアプリケーション内の監査フィールドにアクセスすることができます。これ以外は、監査フィールドが作成されて内部的にエンティティに追加されます。監査フィールド名を使って EJB-QL クエリ内の監査情報にアクセスすることはできますが、エンティティアクセッサーから直接アクセスすることはできません。
column-name が指定されている場合、該当する監査情報は指定のエンティティテーブルのカラムに格納されます。JBoss がテーブルを作成すると jdbc-type と sql-type 要素を使用して、ストレージタイプを定義することができます。
30.4.5. 依存値クラス(DVC: Dependent Value Class) リンクのコピーリンクがクリップボードにコピーされました!
cmp-field タイプである Java クラスの識別に使用する用語です。 デフォルトでは、DVC はシリアル化され、シリアル化形式がデータベースの1カラムに格納されます。ここでは説明しませんが、シリアル化形式でのクラスの長期保管には既知の問題がいくつかあります。
SHIP_LINE1、SHIP_LINE2、SHIP_CITYなどのフィールドや請求書送付先の追加フィールドセットを持つ PURCHASE_ORDER テーブルなど)。この他一般的なデータベース構造としてはエリアコード、外線、内線の別フィールドを持つ電話番号、もしくは複数のフィールドにわたる人名などが挙げられます。DVC では複数のカラムを 1 つの論理フィールドにマッピングすることが可能です。
図30.6 jbosscmp-jdbc dependent-value-class 要素モデル
ContactInfo DVC クラスの例を示します。
dependent-value-class 要素で宣言します。DVC は、クラス要素で宣言される Java クラスタイプで識別されます。各プロパティの永続化はプロパティ要素で宣言されます。 この仕様は cmp-field 要素に基づくため、すぐに理解できるようになっています。この制限も今後のリリースでは削除される予定です。現在は、ローカルエンティティの場合はプライマリキーフィールド、リモートエンティティの場合はエンティティハンドルを格納する設定が提案されています。
dependent-value-classes セクションは内部構造とデフォルトのクラスマッピングを定義します。未知のタイプのフィールドがある場合、JBoss は登録済みの DVC リストを検索します。DVC が見つかったら、カラムセットにこのフィールドを永続化します。それ以外の場合は、単一の列にシリアル化形式で格納されます。JBoss では DVC の継承をサポートしていません。つまり、この検索は宣言タイプのフィールドのみを対象とします。DVC は他の DVC からも構築することができ、JBoss が DVC を発見した場合、DVC ツリー構造をカラムセットにフラット化します。起動時に DVC 回路を発見した場合、JBoss は EJBExceptionを送出します。プロパティのカラム名はデフォルトでは cmp-field の後に下線とプロパティのカラム名が付きます。プロパティが DVC の場合、このプロセスが繰り返されます。たとえば、infoとつけられた ContactInfo を使用する cmp-field の場合は、
cell.areaCodeのようなフラットな観点からプロパティを参照してください。
30.5. コンテナー管理リレーション リンクのコピーリンクがクリップボードにコピーされました!
cmr-field 抽象アクセッサーを作成し、ejb-jar.xml ファイルでリレーションシップを宣言します。次の 2 つの項では、このステップを説明します。
30.5.1. CMR-Field 抽象アクセッサー リンクのコピーリンクがクリップボードにコピーされました!
cmp-fieldsと同じですが、 ただし、値を1つ持つリレーションシップは、それに関連するエンティティのローカルインターフェースを返す必要があります。また、複数の値を持つリレーションシップは java.util.Collection(または java.util.Set) オブジェクトしか返すことができません。たとえば、organization と gangster の 1 対多のリレーションシップを宣言するには、 OrganizationBean クラスで organization から gangster への関係を宣言します。
GangsterBean クラスで宣言することもできます。
30.5.2. リレーションシップの宣言 リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml ファイルでのリレーションシップの宣言は複雑でエラーが発生しやすくなっています。CMR フィールドの配備記述子管理は XDoclet などのツール使用を推奨していますが、記述子について理解しておくことが重要です。以下で organization/gangster リレーションシップの宣言について説明します。
relationships 要素内で ejb-relation 要素付きのリレーションシップを宣言しています。リレーションシップには ejb-relation-name 要素で名前が付けられます。これは jbosscmp-jdbc.xml ファイルで名前によってロールを参照するので重要です。各 ejb-relation には 2 つの ejb-relationship-role 要素があります(リレーションシップの各サイドに一つずつ)。ejb-relationship-role タグは以下のようになります。
- ejb-relationshiprole-name: ロールを識別し、
jbosscmp-jdbc.xmlファイルをマッピングするデータベースとマッチさせるのに使用する任意の要素です。リレーションシップの各サイドに対するロール名はそれぞれ異なるものにしてください。 - multiplicity: これはリレーションシップのこちら側の多重度を示します。
OneまたはManyが値です。この例の場合、1 つの organization から 複数の gangster への関係なので、organization の多重度はOneで、gangster はManyになります。XML 要素と同様、大文字小文字が区別されますので注意してください。 - cascade-delete: この任意の要素が有効な場合、親エンティティが削除されると、子エンティティも削除されます。カスケードの削除は、リレーションシップの他サイドの多重度が 1 であるロールにのみ有効です。デフォルトでは、カスケードの削除はオフに設定されています。
- relationship-role-source
- ejb-name: 必須の要素で、ロールを持つエンティティの名称を付与します。
- cmr-field
- cmr-field-name: エンティティの CMR フィールドの名前がある場合は、その名称のことです。
- cmr-field-type: フィールドがコレクションタイプであれば、これは CMR フィールドのタイプです。
java.util.Collectionまたはjava.util.Setになります。
30.5.3. 関係マッピング リンクのコピーリンクがクリップボードにコピーされました!
ejb-relation 要素を使い jbosscmp-jdbc.xml 記述子の relationships セクションで宣言します。リレーションシップは ejb-jar.xml ファイルの ejb-relation-name で識別されます。jbosscmp-jdbc.xmlejb-relation 要素のコンテンツモデルを図30.7「jbosscmp-jdbc.xml ejb-relation 要素のコンテンツモデル」
図30.7 jbosscmp-jdbc.xml ejb-relation 要素のコンテンツモデル
Organization-Gangster リレーションシップのリレーションシップマッピング宣言の基本テンプレートは次のようになります。
ejb-relation-name を宣言すれば、リレーションシップはread-only と read-time-out 要素を使用して読み取り専用として宣言することができます。これはエンティティ要素の相手側と同じセマンティクスを持ちます。
ejb-relation 要素は foreign-key-mapping 要素、または relation-table-mapping 要素を含む必要があります。詳しくは 「外部キーマッピング」 および 「関係テーブルのマッピング」 に説明します。次のセクションに説明するように、このエレメントは ejb-relationship-role 要素のペアも含みます。
30.5.3.1. リレーションシップロールマッピング リンクのコピーリンクがクリップボードにコピーされました!
ejb-relationship-role 要素はそれぞれリレーションシップのエンティティ特有のマッピング情報を含みます。ejb-relationship-role 要素のコンテンツモデルを 図30.8「jbosscmp-jdbc ejb-relationship-role 要素のコンテンツモデル」に示します。
図30.8 jbosscmp-jdbc ejb-relationship-role 要素のコンテンツモデル
- ejb-relationship-role-name: 必須であるこの要素は、この設定が適用されるロール名を付与します。名称は
ejb-jar.xmlファイルでこのリレーションシップに対して宣言されたロールのうち一つの名称と一致させる必要があります。 - fk-constraint: この任意の要素は true/false の値で、リレーションシップのこちら側のテーブルに対して外部キー制約を追加するかどうか示すものです。デプロイメント実行中に JBoss がプライマリテーブルとこのプライマリテーブルに関連するテーブルを両方作成した場合、JBoss は制約のみを追加生成します。
- key-fields: 現行エンティティのプライマリキーフィールドのマッピングについて、関係テーブル、または関連するオブジェクトのいずれにマッピングするかを指定します。
key-fields要素は、現在のエンティティのプライマリキーフィールドごとにkey-fields要素を1つ含む必要があります。リレーションのこちら側に外部キーマッピングが必要なければ、key-fields要素を空にしておくこともできます。この例は、1 対多のリレーションシップの多サイドになります。この要素の詳細については以下に説明します。 - read-ahead: この任意の要素は、リレーションシップのキャッシュを制御します。このオプションについては、「リレーションシップ」で説明します。
- batch-cascade-delete: このリレーションシップにおけるカスケード削除は、SQL ステートメント1つで実行しなければならないことを示します。この場合、このリレーションシップは
ejb-jar.xmlでbatch-deleteとしてマークしておく必要があります。
key-fields 要素は、現行のエンティティのプライマリキーフィールドごとに key-fields 要素を1つ含みます。key-field 要素は、エンティティの cmp-field 要素と同じ構文を使います。ただし、key-field は not-null オプションをサポートしません。relation-table のキーフィールドはテーブルのプライマリキーなので、自動的に not null になります。一方で、外部キーフィールドはデフォルトで null 可能にしておく必要があります。CMP 仕様は ejbPostCreateメソッドによってデータベースに挿入し、ejbPostCreateによる CMR の変更箇所をピックアップするため、更新する必要があります。EJB 仕様では ejbPostCreateまではリレーションシップを修正できないため、外部キーは最初は null に設定されます。削除の場合にも同様の問題が発生します。この挿入動作は jboss.xmlinsert-after-ejb-post-create コンテナー設定フラグを使用して変更することもできます。デフォルトで insert-after-ejb-post-create を使用する新しい bean 設定の作成を以下の例に示します。
ejbCreate の外部キーフィールドを生成するだけです。
図30.9 jbosscmp-jdbc key-fields 要素のコンテンツモデル
key-field 要素に含まれる各種要素の詳細については、以下に説明します。
- field-name: この必須要素は、マッピングを適用するフィールドを識別します。この名称は、現行エンティティのプライマリキーフィールドに一致させる必要があります。
- column-name: プライマリキーフィールドが格納される列の名称を指定する場合、このエレメントを使用します。このリレーションシップが
foreign-key-mappingを使用する場合、この列は関連するエンティティのテーブルに追加されます。このリレーションシップがrelation-table-mappingを使用する場合、この列はrelation-tableに追加されます。この要素はマッピング依存値クラスには対応しません。代わりにプロパティ要素を使用します。 - jdbc-type: JDBC
PreparedStatement内にパラメーターを設定する、または JDBC ResultSet からデータをロードする場合に使用される JDBC タイプです。有効なタイプはjava.sql.Typesに定義されます。 - sql-type: このフィールドの create テーブルステートメントで使用される SQL タイプです。有効なタイプは、データベースベンダーのみにて制限されます。
- property: 依存値クラスのプライマリキーフィールドのマッピングを指定する場合、この要素を使用します。
- dbindex: この任意フィールドがあると、サーバーはデータベース内の該当カラムにインデックスを作成する必要があることを示します。このインデックス名は
fieldname_indexになります。
30.5.3.2. 外部キーマッピング リンクのコピーリンクがクリップボードにコピーされました!
key-mapping 要素を ejb-relation 要素に追加して宣言するだけです。
ejb-relationship-role で宣言した key-fields は関連エンティティのテーブルに追加されます。key-fields 要素が空の場合、外部キーはそのエンティティに対して作成されません。1 対多のリレーションシップでは、多の側(例の Gangster )は空のkey-fields 要素が必要で、1 の側の(例の Organization )要素は key-fields マッピングが必要です。1 対 1 のリレーションシップでは 1 つ、あるいは両方のロールに外部キーがあります。
Organization-Gangster リレーションシップの完全な外部キーマッピングを外部キー要素を太字で強調表示して以下に示します。
30.5.3.3. 関係テーブルのマッピング リンクのコピーリンクがクリップボードにコピーされました!
relation-table-mapping 要素を使用して定義します。コンテンツモデルを以下に示します。
図30.10 jbosscmp-jdbc relation-table-mapping 要素のコンテンツモデル
Gangster-Job リレーションシップの relation-table-mapping が以下に示していますが、テーブルマッピング要素を太字で強調表示しています。
例30.1 jbosscmp-jdbc.xml Relation-table マッピング
relation-table-mapping 要素は entity 要素で使用可能なオプションのサブセットを含みます。この要素に関する詳細な説明をここで繰り返します。
- table-name: この任意の要素は、このリレーションシップのデータを格納するテーブル名を付与します。デフォルトのテーブル名は、エンティティと
cmr-field名に基づいて付与されます。 - datasource: この任意の要素は、データソースのルックアップに使用される
jndi-nameになります。データベース接続はすべてデータソースから取得されます。エンティティにさまざまなデータソースを持たせると、finder およびejbSelectでクエリできるドメインを大幅に制約することになるため推奨しません。 - datasourcemapping: この任意の要素では、使用する
type-mappingの名称を指定することができます。 - create-table: この任意の要素が true の場合、JBoss はエンティティのテーブルの作成を試行しなければなりません。アプリケーションをデプロイすると、JBoss はテーブル作成の前にすでにテーブルが存在していないか確認します。テーブルが見つかった場合、ログに記録されるだけでテーブルは作成されませんこのオプションは、開発の初期段階でテーブル構造が頻繁に変わる場合に非常に役立ちます。
- post-table-create: この任意要素はデータベーステーブルの作成直後に実行されるべき任意の SQL ステートメントを指定します。このコマンドは
create-tableが true でテーブルが以前に存在しない場合にのみ実行されます。 - remove-table: この任意の要素が true の場合、アプリケーションがアンデプロイされると、
relation-tableのドロップを試行します。このオプションは、開発の初期段階でテーブル構造が頻繁に変わる場合に非常に役立ちます。 - row-locking:この任意の要素が true の場合、トランザクションでロードされたすべての行を JBoss がロックすることを意味します。ほとんどのデータベースがエンティティのロード時に
SELECT FOR UPDATE構文を使用してこれを実装しますが、実際の構文は、このエンティティで使用されるdatasource-mapping内のrow-locking-templateで決まります。 - pk-constraint: この任意の要素は、true であれば、テーブル作成時に JBoss がプライマリキー制約を追加することを意味します。
30.6. クエリ リンクのコピーリンクがクリップボードにコピーされました!
30.6.1. Finder と Select 宣言 リンクのコピーリンクがクリップボードにコピーされました!
GangsterHome インターフェースで findBadDudes_ejbql finder を宣言します。ejbql 接尾辞はここでは必要ありません。これは単に、異なるタイプのクエリ仕様を分類するため便宜上使用する命名規則です。
FinderException を送出する必要があります。以下のコードで select メソッドを宣言します。
30.6.2. EJB-QL 宣言 リンクのコピーリンクがクリップボードにコピーされました!
findByPrimaryKey を除く)には ejb-jar.xml ファイルで定義した EJB-QL クエリが必要です。EJB-QL クエリは、エンティティ要素に含まれるクエリ要素で宣言します。以下に findBadDudes_ejbql および ejbSelectBoss_ejbql クエリの宣言を示します。
- EJB-QL は型付言語で、つまり類似する型の比較しかできません(例:ストリングはストリングとの比較しかできないなど)。
- 同値比較では、変数(一価パス)は左側に記載する必要があります。以下に例を示します。
g.hangout.state = 'CA' Legal 'CA' = g.shippingAddress.state NOT Legal 'CA' = 'CA' NOT Legal (r.amountPaid * .01) > 300 NOT Legal r.amountPaid > (300 / .01) Legal
g.hangout.state = 'CA' Legal
'CA' = g.shippingAddress.state NOT Legal
'CA' = 'CA' NOT Legal
(r.amountPaid * .01) > 300 NOT Legal
r.amountPaid > (300 / .01) Legal
- パラメーターは java.sql.PreparedStatement のようにベース 1 インデックスを使用します。
- パラメーターは比較の右側に必ず記載されます。以下に例を示します。
gangster.hangout.state = ?1 Legal ?1 = gangster.hangout.state NOT Legal
gangster.hangout.state = ?1 Legal
?1 = gangster.hangout.state NOT Legal
30.6.3. EJB-QL を SQL マッピングにオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml ファイルでオーバーライドできます。finder、または select は EJB-QL 宣言に必要ですが、ejb-ql 要素は空のままにして構いません。現在、SQL は JBossQL、DynamicQL、DeclaredSQL、または BMP スタイルカスタムの ejbFind メソッドでオーバーライドできます。EJB-QL のオーバーライドは EJB の仕様に対して規格外の拡張子であるため、この拡張子を使用するとアプリケーションのポータビリティ(移植性)が制限されます。BMP カスタムファインダーを除く EJB-QL のオーバーライドはすべて、jbosscmp-jdbc.xml ファイルの query 要素を使用して宣言されます。コンテンツモデルを 図30.11「jbosscmp-jdbc query 要素のコンテンツモデル」に示します。
図30.11 jbosscmp-jdbc query 要素のコンテンツモデル
- description: クエリに対するオプションの記述子です。
- query-method: 必須の要素で、設定するクエリメソッドを指定します。これは
ejb-jar.xmlファイルでこのエンティティに対して宣言されたquery-methodと一致する必要があります。 - jboss-ql: EJB-QL クエリの代わりに使用される JBossQL クエリです。JBossQL ついては 「JBossQL」で説明します。
- dynamic-ql:メソッドがダイナミッククエリであり、EJB-QL クエリではないことを示します。ダイナミッククエリについては、「DynamicQL」で説明しています。
- declared-sql: このクエリは EJB-QL の代わりに宣言した SQL を使用します。宣言した SQL については、「DeclaredSQL」で説明しています。
- read-ahead: この任意の要素により、クエリで参照したエンティティ付きで使用する追加フィールドのロードを最適化します。これについては、「最適化ローディング」で詳しく説明しています。
30.6.4. JBossQL リンクのコピーリンクがクリップボードにコピーされました!
ORDER BY、OFFSET および OFFSET 句、IN および LIKE 演算子のパラメーター、COUNT、MAX、MIN、AVG、SUM、UCASE および LCASE 関数をサポートしています。また、クエリは select メソッドに対する SELECT 句の関数を含みます。
jboss-ql 要素付きの jbosscmp-jdbc.xml ファイルで宣言されます。以下に JBossQL 宣言の例を紹介します。
SELECT t0_g.id
FROM gangster t0_g
WHERE t0_g.badness > ?
ORDER BY t0_g.badness DESC
SELECT t0_g.id
FROM gangster t0_g
WHERE t0_g.badness > ?
ORDER BY t0_g.badness DESC
LIMIT と OFFSET 関数を使い、ファインダ結果をブロックで読み出す機能も備わっています。たとえば、実行した大量のジョブを繰り返すには、以下の findManyJobs_jbossql finder を定義します。
30.6.5. DynamicQL リンクのコピーリンクがクリップボードにコピーされました!
dynamic-ql 要素付きの jbosscmp-jdbc.xml ファイルで宣言します。以下に ejbSelectGenericの宣言を示します。
30.6.6. DeclaredSQL リンクのコピーリンクがクリップボードにコピーされました!
WHERE 句を使ったクエリを制限しています。declared-sql 要素のコンテンツモデルは 図30.12「jbosscmp-jdbc declared-sql 要素のコンテンツモデル」に示しています。
図30.12 jbosscmp-jdbc declared-sql 要素のコンテンツモデル
- select:
select要素は選択する対象を指定するもので、以下の要素で構成されています。- distinct:この空の要素がある場合、JBoss は
DISTINCTキーワードを追加してSELECT句を生成します。デフォルトでは、メソッドがjava.util.Setを返した場合、DISTINCTを使用するように設定されています。 - ejb-name: 選択するエンティティの
ejb-nameを示します。この項目は、クエリーが select メソッドの場合のみ必須です。 - field-name: 指定したエンティティから選択される CMP フィールドの名称です。デフォルトではエンティティ全体を選択するよう設定されています。
- alias: メインの select テーブルに使用するエイリアスを指定します。デフォルトは
ejb-nameを使用します。 - additional-columns: finder で任意のカラムの命令を実行、あるいは select の集約関数に対応するために選択されるカラムを宣言します。
- from:
from要素は、生成済みのFROM句に追加する SQL を宣言します。 - where:
where要素は クエリー用のWHERE句を宣言します。 - order:
order要素はクエリー用のORDER句を宣言します。 - other:
other要素はクエリーの最後に追加する SQL を宣言します。
SELECT id FROM gangster WHERE badness > ? ORDER BY badness DESC
SELECT id
FROM gangster
WHERE badness > ?
ORDER BY badness DESC
SELECT および FROM 句を生成します。ご希望であれば、自動生成された FROM 句の末尾に追加される FROM 句を指定することができます。以下に FROM 句を追加した DeclaredSQL 宣言の例を示します。
SELECT DISTINCT boss.id
FROM gangster boss, gangster g, organization o
WHERE (LCASE(g.name) = ? OR LCASE(g.nick_name) = ?) AND
g.organization = o.name AND o.the_boss = boss.id
SELECT DISTINCT boss.id
FROM gangster boss, gangster g, organization o
WHERE (LCASE(g.name) = ? OR LCASE(g.nick_name) = ?) AND
g.organization = o.name AND o.the_boss = boss.id
FROM 句はコンマで始まりますので注意してください。これは、コンテナーが生成された FROM 句の末尾に宣言した FROM 句を追加するためです。FROM 句は SQL JOIN ステートメントで始まる場合もあります。select メソッドなので、選択されるエンティティを宣言する select要素が必要です。エイリアスもクエリに対して宣言されますので、注意してください。エイリアスが宣言されない場合、table-name をエイリアスとして使用します。つまり、SELECT 句が table_name.field_nameスタイルのカラム宣言になります。データベースベンダーによってはこの構文をサポートしていませんので、エイリアスの宣言を推奨します。任意でdistinct 要素により SELECT 句は SELECT DISTINCT 宣言を使用します。DeclaredSQL 宣言は CMP フィールドを選択する select メソッドでも使用することができます。
Organization が運営している場所の郵便番号を返す select をオーバーライドする場合の例を以下に示します。
SELECT DISTINCT hangout.zip
FROM location hangout, organization o, gangster g
WHERE LCASE(o.name) = ? AND o.name = g.organization AND g.hangout = hangout.id
ORDER BY hangout.zip
SELECT DISTINCT hangout.zip
FROM location hangout, organization o, gangster g
WHERE LCASE(o.name) = ? AND o.name = g.organization AND g.hangout = hangout.id
ORDER BY hangout.zip
30.6.6.1. パラメーター リンクのコピーリンクがクリップボードにコピーされました!
- simple: シンプルパラメーターは既知(マッピング済みの)DVC やエンティティ以外のあらゆるタイプを指します。シンプルパラメーターは
{0}などの引数のみを含みます。シンプルパラメーターが設定されている場合、パラメーターを設定する JDBC タイプは、エンティティに対するdatasourcemappingで決定します。未知の DVC はシリアル化され、パラメーターとして設定されます。WHERE 句では BLOB 値の使用をサポートしていないデータベースがほとんどですので、注意してください。 - DVC: DVC パラメーターは既知の(マッピング済み)DVC になります。DVC パラメーターはシンプルプロパティ(別の DVC ではないもの)を逆参照する必要があります。たとえば、タイプ
ContactInfoの CVS プロパティがある場合、有効なパラメーターの宣言は{0.email}および{0.cell.areaCode}になり、{0.cell}にはなりません。パラメーターの設定に使用する JDBC タイプは、プロパティのクラスタイプとエンティティのdatasourcemappingにより決まります。パラメーターの設定に使用する JDBC タイプは、dependent-value-class要素でこのプロパティに対して宣言した JDBC タイプになります。 - entity: エンティティパラメーターは、アプリケーションにある任意のエンティティになります。エンティティパラメーターは、DVC プライマリキーフィールドのシンプルプライマリキーフィールド、またはシンプルプロパティを逆参照する必要があります。たとえば、タイプ
Gangsterのパラメーターがある場合、有効なパラメーター宣言は{0.gangsterId}になります。タイプContactInfoのプライマリキーフィールドの名前が付いたエンティティがある場合、valid parameter宣言は{0.info.cell.areaCode}になります。エンティティのプライマリキーの構成要素であるフィールドのみ逆参照できます(今後のバージョンではこの制限がなくなる予定です)。パラメーターの設定に使用する JDBC タイプは、エンティティ宣言でこのフィールドに対して宣言した JDBC タイプになります。
30.6.7. EJBQL 2.1 と SQL92 のクエリ リンクのコピーリンクがクリップボードにコピーされました!
standardjbosscmp-jdbc.xmlに指定しています。
ql-compiler 要素で SQL92 コンパイラーを指定するだけです。
jbosscmp-jdbc.xmlで指定することもできます。初期のクエリの一つを使用した例を以下に紹介します。
read-ahead ストラテジに関わらず、エンティティの全フィールドを選択することです。たとえば、クエリがon-loadread-ahead ストラテジで設定されている場合、最初のクエリには全フィールドが含まれ、プライマリキーフィールドだけが ResultSet から読み込まれます。次に、他のフィールドは先読みキャッシュにロードされます。デフォルトのロードグループ* を備えた on-findread-ahead は 期待通りに動作します。
30.6.8. BMP カスタムファインダー リンクのコピーリンクがクリップボードにコピーされました!
ejb-jar.xml または jbosscmp-jdbc.xml ファイルで宣言したその他の実装に優先して、このカスタムファインダーを呼び出します。以下のシンプルな例に、プライマリキーの集まりによるエンティティを示します。
30.7. 最適化ローディング リンクのコピーリンクがクリップボードにコピーされました!
30.7.1. ローディングのシナリオ リンクのコピーリンクがクリップボードにコピーされました!
findAll_none の呼び出しで、JBoss は以下のクエリを実行します。
SELECT t0_g.id
FROM gangster t0_g
ORDER BY t0_g.id ASC
SELECT t0_g.id
FROM gangster t0_g
ORDER BY t0_g.id ASC
findAll に対して 1 つのクエリを、また、見つかった各要素にアクセスするのに 1 つのクエリを実行するため、過剰な数のクエリが実行されます。この動作の原因は、JBoss コンテナ内でのクエリ結果の処理方法と関係があります。クエリが実行されると、選択された実際のエンティティ bean が返されるように見えますが、JBoss は実際は一致するエンティティのプライマリキーを戻すだけで、そのエンティティに対してメソッドが呼び出されるまで、エンティティをロードしません。これは n+1 問題として知られ、以降のセクションで説明する read-ahead ストラテジで対処します。
hangout および organization フィールドをロードしますが、これはアクセスされることはありません。(分かりやすくするために、複雑な contactInfo フィールドを無効にしてあります)。
| id | name | nick_name | badness | hangout | organization |
|---|---|---|---|---|---|
| 0 | Yojimbo | Bodyguard | 7 | 0 | Yakuza |
| 1 | Takeshi | Master | 10 | 1 | Yakuza |
| 2 | Yuriko | Four finger | 4 | 2 | Yakuza |
| 3 | Chow | Killer | 9 | 3 | Triads |
| 4 | Shogi | Lightning | 8 | 4 | Triads |
| 5 | Valentino | Pizza-Face | 4 | 5 | Mafia |
| 6 | Toni | Toothless | 2 | 6 | Mafia |
| 7 | Corleone | Godfather | 6 | 7 | Mafia |
30.7.2. Load Groups リンクのコピーリンクがクリップボードにコピーされました!
Gangster など) を持つ CMR フィールドおよび CMP フィールドの名前が入っています。設定例を次に示します。
basic および contact info という2 つのロードグループが宣言されています。ロードグループは相互排他的である必要はないことに注意してください。たとえば、両方のロードグループに nickName フィールドが入っています。JBoss は、宣言されたロードグループに加えて、エンティティ内の外部キーを持つすべての CMR フィールドおよび CMP フィールドを含んでいる * (スターグループ) というグループを自動的に追加します。
30.7.3. Read-ahead リンクのコピーリンクがクリップボードにコピーされました!
on-find および on-load) を実装して、前項で挙げたローディングの問題を最適化します。read-ahead 中にロードされた余分なデータは、すぐにメモリ内のエンティティオブジェクトと関連付けられません。なぜなら、JBoss においてエンティティは実際にアクセスされるまで実体化されないからです。その代わり、これはプレロードキャッシュに格納され、エンティティにロードされるまで、あるいはトランザクションの終わりが現れるまで、そこにとどまります。以降のセクションでは、read-ahead ストラテジーについて説明します。
30.7.3.1. on-find リンクのコピーリンクがクリップボードにコピーされました!
on-find ストラテジーは、クエリが呼び出されると、追加のカラムを読み込みます。クエリが on-find 最適化されている場合、クエリが実行されると JBoss は次のクエリを実行します。
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
| id | name | nick_name | badness | hangout | organization |
|---|---|---|---|---|---|
| 0 | Yojimbo | Bodyguard | 7 | 0 | Yakuza |
| 1 | Takeshi | Master | 10 | 1 | Yakuza |
| 2 | Yuriko | Four finger | 4 | 2 | Yakuza |
| 3 | Chow | Killer | 9 | 3 | Triads |
| 4 | Shogi | Lightning | 8 | 4 | Triads |
| 5 | Valentino | Pizza-Face | 4 | 5 | Mafia |
| 6 | Toni | Toothless | 2 | 6 | Mafia |
| 7 | Corleone | Godfather | 6 | 7 | Mafia |
read-ahead ストラテジーと load-group は、query 要素に定義されます。read-ahead ストラテジーが query 要素に宣言されていない場合は、entity 要素または defaults 要素に宣言されたストラテジーが使用されます。on-find 設定は次のとおりです。
on-find ストラテジーには、選択されたすべてのエンティティについて追加データをロードしなければならないという問題があります。Web アプリケーションでは通常、ページ上で固定された数の結果だけがレンダリングされます。プレロードされたデータはトランザクションの長さだけ有効であり、1 トランザクションは Web HTTP の 1 ヒットに制限されるので、プレロードされたデータの大半は使用されません。次項で説明する on-load ストラテジーでは、この問題の影響を受けません。
30.7.3.1.1. Left join read ahead リンクのコピーリンクがクリップボードにコピーされました!
on-findread-ahead ストラテジーが強化されたものです。1 つの SQL クエリで、ベースインスタンスからのフィールドだけでなく、CMR ナビゲーションによりベースインスタンスから到達できる関連インスタンスもプレロードすることができます。CMR ナビゲーションの深さに対する制限はありません。また、ナビゲーションおよびリレーションシップタイプのマッピングで使用される CMR フィールドのカーディナリティに対する制限もありません。すなわち、外部キーと関連テーブルマッピングスタイルの両方がサポートされます。それでは、例をいくつか見ていきましょう。エンティティとリレーションシップの宣言を以下に示しています。
30.7.3.1.2. D#findByPrimaryKey リンクのコピーリンクがクリップボードにコピーされました!
Dがあるとします。findByPrimaryKey に対して生成される一般的な SQL は、次のようになります。
SELECT t0_D.id, t0_D.name FROM D t0_D WHERE t0_D.id=?
SELECT t0_D.id, t0_D.name FROM D t0_D WHERE t0_D.id=?
findByPrimaryKey の実行中に、2 つのコレクション値 CMR フィールド bs および csもプレロードすることにします。
left-join では、一括読み込みを行いたいリレーションを宣言します。生成される SQL は次のようになります。
D では、それに関連するすべての Bと Cをプリロードし、それをデータベースからではなく先読みキャッシュからロードするインスタンスにアクセスすることができます。
30.7.3.1.3. D#findAll リンクのコピーリンクがクリップボードにコピーされました!
D への findAll メソッドはD 関連をすべて選択しますが、この findAll メソッドを最適化することができます。通常の findAll クエリは次のようになります。
SELECT DISTINCT t0_o.id, t0_o.name FROM D t0_o ORDER BY t0_o.id DESC
SELECT DISTINCT t0_o.id, t0_o.name FROM D t0_o ORDER BY t0_o.id DESC
left-join 要素をクエリーに追加するだけで結構です。
findAll クエリは、各 D オブジェクトに対して、関連する B および C オブジェクトをプレロードするようになりました。
30.7.3.1.4. A#findAll リンクのコピーリンクがクリップボードにコピーされました!
A をプレロードしようと思います。
- CMR フィールド
parentでAから到達するその親 (セルフリレーション) - CMR フィールド
bでAから到達するB、および CMR フィールドcでBから到達する関連のC - 今回は CMR フィールド b2 で
Aから到達するB、およびそれに関連付けられた、CMR フィールド c で B から到達するC
SELECT t0_o.id, t0_o.name FROM A t0_o ORDER BY t0_o.id DESC FOR UPDATE
SELECT t0_o.id, t0_o.name FROM A t0_o ORDER BY t0_o.id DESC FOR UPDATE
A のインスタンスから CMR をナビゲートすることができます。
30.7.3.1.5. A#findMeParentGrandParent リンクのコピーリンクがクリップボードにコピーされました!
left-join 宣言を使用します。
left-join メタデータを取り除けば、次のようになります。
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B2_FK, t0_o.PARENT FOR UPDATE
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B2_FK, t0_o.PARENT FOR UPDATE
30.7.3.2. on-load リンクのコピーリンクがクリップボードにコピーされました!
on-load ストラテジーは、あるエンティティがロードされるときに、いくつかのエンティティの追加データをブロックでロードするもので、要求されたエンティティから開始し、選択された順序で次のいくつかのエンティティをロードします。このストラテジーは、find または select の結果が順方向にアクセスされるという理論に基づきます。クエリーが実行されると、JBoss は、見つかったエンティティの順番をリストキャッシュに格納します。後で、エンティティのいずれかがロードされるとき、JBoss はこのリストを使用して、ロードするエンティティのブロックを決定します。キャッシュに格納するリスト数は、エンティティの list-cachemax 要素で指定します。このストラテジーは、on-find ストラテジーでデータがロードされないという問題があるときにも使用されます。
on-find ストラテジーと同様に、on-load は read-ahead 要素で宣言します。この例の on-load 設定を次に示します。
SELECT t0_g.id
FROM gangster t0_g
ORDER BY t0_g.id ASC
SELECT t0_g.id
FROM gangster t0_g
ORDER BY t0_g.id ASC
name、nickName、badness フィールドをロードするのに、次の 2 つのクエリーを実行するだけでよくなります。
| id | name | nick_name | badness | hangout | organization |
|---|---|---|---|---|---|
| 0 | Yojimbo | Bodyguard | 7 | 0 | Yakuza |
| 1 | Takeshi | Master | 10 | 1 | Yakuza |
| 2 | Yuriko | Four finger | 4 | 2 | Yakuza |
| 3 | Chow | Killer | 9 | 3 | Triads |
| 4 | Shogi | Lightning | 8 | 4 | Triads |
| 5 | Valentino | Pizza-Face | 4 | 5 | Mafia |
| 6 | Toni | Toothless | 2 | 6 | Mafia |
| 7 | Corleone | Godfather | 6 | 7 | Mafia |
30.7.3.3. none リンクのコピーリンクがクリップボードにコピーされました!
none ストラテジーは、実は反ストラテジーです。このストラテジーによって、システムはデフォルトの lazy-load コードに戻ります。具体的には、どのデータも先読みせず、見つかったエンティティの順序を記憶しません。この結果、この章の先頭で紹介したクエリーとパフォーマンスになります。none ストラテジーは、read-ahead 要素で宣言します。read-ahead 要素に page-size 要素または eager-load-groupが含まれる場合、それは無視されます。次の例で none ストラテジーが宣言されています。
30.8. ローディングプロセス リンクのコピーリンクがクリップボードにコピーされました!
30.8.1. コミットオプション リンクのコピーリンクがクリップボードにコピーされました!
A、B、C、Dという 4 つの commit オプションをサポートしています。最初の 3 つは Enterprise JavaBeans 仕様で説明されていますが、最後のものは JBoss に固有のものです。各 commit オプションの詳細は次のとおりです。
- A: JBoss は、それがデータベースの唯一のユーザーであるとみなします。したがって、JBoss は各トランザクション間のエンティティの現行値をキャッシュ化でき、大幅に性能が向上するでしょう。そのため、JBoss で管理されるデータは JBoss 外では変更できません。たとえば、別のプログラムでデータを変更するか、(JBoss 内であっても) ダイレクト JDBC を利用してデータを変更すると、データベースの状態が矛盾してしまいます。
- B: JBoss は、データベースのユーザーが複数存在するとみなしますが、トランザクション間のエンティティに関するコンテキスト情報を保持します。 このコンテキスト情報は、エンティンティのローディングを最適化するのに使用されます。これはデフォルトの commit オプションです。
- C: JBoss は、トランザクションの終わりにすべてのエンティティコンテキスト情報を破棄します。
- D: これは JBoss 固有の commit オプションです。このオプションは、指定された期間のみデータが有効であるという点を除けば、commit オプション
Aと似ています。
jboss.xml ファイルで宣言します。このファイルについて詳しくは 29章JBoss 上の EJB を参照してください。以下の例は、アプリケーション内のすべてのエンティティ bean に対して commit オプションを A に変更しています。
例30.2 jboss.xml Commit オプション宣言
30.8.2. 一括読み込みプロセス リンクのコピーリンクがクリップボードにコピーされました!
eager-load-group を使用します。クエリーでエンティティが選択されていない場合、または最終クエリーが none read-ahead ストラテジーを使用していた場合は、JBoss はエンティティに宣言されたデフォルトの eager-load-group を使用します。次の設定例では、gangster エンティティ bean に対するデフォルト eager-load-group として basic ロードグループが設定されています。
- エンティティコンテキストがまだ有効な場合はローディングは必要なく、したがってローディングプロセスは完了です。commit オプション
Aを使用している場合、または commit オプションDを使用していてデータがまだタイムアウトしていない場合には、エンティティコンテキストは有効になります。 - エンティティコンテキストに残っているデータがフラッシュされます。これにより、古いデータが新しいデータに入り込むことはなくなります。
- プライマリキー値がプライマリキーフィールドに戻ります。プライマリキーオブジェクトは、実際にはフィールドとは無関係で、ステップ 2 でのフラッシュ後に再ロードする必要があります。
- このエンティティのプレロードキャッシュ内のすべてのデータが、フィールドにロードされます。
- まだロードする必要がある追加のフィールドを JBoss が決定します。通常、ロードするフィールドは、エンティティの eager-load グループによって決まりますが、
on-findまたはon-load先読みストラテジーを持つクエリーまたは CMR フィールドを使用してエンティティを特定した場合には、オーバーライドすることができます。すべてのフィールドがすでにロードされていた場合、ロードプロセスはステップ 7 に進んでください。 - クエリーを実行して必要なカラムを選択します。このエンティティが
on-loadストラテジーを使用している場合、「on-load」 で説明したとおりに 1 ページのデータがロードされます。現行のエンティティのデータがコンテキストに格納され、他のエンティティのデータはプレロードキャッシュに格納されます。 - エンティティの
ejbLoadメソッドが呼び出されます。
30.8.3. 遅延ローディングプロセス リンクのコピーリンクがクリップボードにコピーされました!
lazy-load-group のフィールドをすべてロードします。JBoss は set join を実行し、その後、すでにロードされているフィールドがあれば削除します。設定例を次に示します。
getName() を呼び出すと、JBoss は、name、nickName、badnessを、それらがまだロードされていないとみなしてロードします。bean プロバイダーが getNickName()、name、nickName、badness、contactInfo、hangout がロードされます。遅延ローディングプロセスの詳細は次のとおりです。
- このエンティティのプレロードキャッシュ内のすべてのデータが、フィールドにロードされます。
- プレロードキャッシュによってフィールド値がロードされていた場合には、遅延ロードプロセスは終了します。
- JBoss は、このフィールドを含むすべての遅延ロードグループを見つけ出し、このグループに対して set join を実行し、すでにロードされていたフィールドがあれば削除します。
- クエリーを実行して必要なカラムを選択します。基本ロードプロセスと同様に、JBoss はエンティティのブロックをロードする場合があります。現行のエンティティのデータがコンテキストに格納され、他のエンティティのデータはプレロードキャッシュに格納されます。
30.8.3.1. リレーションシップ リンクのコピーリンクがクリップボードにコピーされました!
on-load でブロックロードすることが可能で、現在求められているエンティティの値および次のいくつかのエンティティに対する CMR フィールドの値がロードされることを意味します。クエリーとしては、on-find を使用して、関連するエンティティのフィールド値をプレロードすることができます。
例30.3 リレーションシップの遅延ローディングのコード例
findAll_onfind クエリーの設定は on-find セクションから変わっていません。Locationエンティティおよび Gangster-Hangout リレーションシップの設定は次のとおりです。
例30.4 jbosscmp-jdbc.xml リレーションシップ の遅延ローディング設定
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
city、state、zipフィールドをロードします。
| id | name | nick_name | badness | hangout | id | city | st | zip |
|---|---|---|---|---|---|---|---|---|
| 0 | Yojimbo | Bodyguard | 7 | 0 | 0 | San Fran | CA | 94108 |
| 1 | Takeshi | Master | 10 | 1 | 1 | San Fran | CA | 94133 |
| 2 | Yuriko | Four finger | 4 | 2 | 2 | San Fran | CA | 94133 |
| 3 | Chow | Killer | 9 | 3 | 3 | San Fran | CA | 94133 |
| 4 | Shogi | Lightning | 8 | 4 | 4 | San Fran | CA | 94133 |
| 5 | Valentino | Pizza-Face | 4 | 5 | 5 | New York | NY | 10017 |
| 6 | Toni | Toothless | 2 | 6 | 6 | Chicago | IL | 60661 |
| 7 | Corleone | Godfather | 6 | 7 | 7 | Las Vegas | NV | 89109 |
30.8.4. 遅延ローディングの結果セット リンクのコピーリンクがクリップボードにコピーされました!
EJBLocalObject または CMP フィールド値のコレクションを受け取り、この後それを反復することができます。結果セットが大きい場合は、この方法は効率的ではありません。場合によっては、クライアントがコレクションから対応する値の読み込みを試行するまでは、結果セットにある次の行の読み込みを遅らせるほうがよい場合があります。lazy-resultset-loading 要素を使用することで、クエリーに対するこの動作を起こさせることができます。
Collection を扱う場合には、特別な注意が必要です。iterator() への最初の呼び出しによって、ResultSetから読み込むという特別な Iterator を返します。この Iterator が使い果たされるまで、その後の iterator() に対する呼び出しや add() メソッドに対する呼び出しは除外されます。remove() および size() メソッドはそのまま期待通りに機能します。
30.9. トランザクション リンクのコピーリンクがクリップボードにコピーされました!
on-find 最適化クエリーを使用した例を用いて、トランザクションなしで実行した場合の性能上の影響をデモンストレーションし、これをラッパートランザクションなしで実行します。コード例は次のとおりです。
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness FROM gangster t0_g WHERE t0_g.id < 4 ORDER BY t0_g.id ASC
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
WHERE t0_g.id < 4
ORDER BY t0_g.id ASC
図30.13 トランザクションなし on-find 最適化クエリー実行
assembly-descriptor で Required または RequiresNewtrans-attribute をメソッドに付けなければなりません。コードを EJB で実行していない場合は、ユーザートランザクションが必要です。次のコードでは、ユーザートランザクションによって、宣言されたメソッドに対する呼び出しをラップしています。
30.10. 楽観的ロッキング リンクのコピーリンクがクリップボードにコピーされました!
select for UPDATE WHERE ... ステートメントを使用して行われます。
jbosscmp-jdbc.xml 記述子の optimistic-locking 要素を使用して指定します。optimistic-locking 要素のコンテンツモデルを次に示し、その後に各要素の説明をします。
図30.14 jbosscmp-jdbc optimistic-locking 要素コンテンツモデル
- group-name: この要素は、
load-groupのフィールドに基づく楽観ロッキングであることを指定します。この要素のこの値は、エンティティのload-group-nameのいずれかと一致していなければなりません。このグループ内のフィールドが楽観ロッキングに使用されます。 - modified-strategy: この要素は、変更フィールドをベースにした楽観ロッキングであることを指定します。このストラテジーは、トランザクション中に修正されたフィールドが楽観ロッキングに使用されることを意味します。
- read-strategy:この要素は、読み込まれたフィールドに基づく楽観ロッキングであることを指定します。このストラテジーは、トランザクション内の読み込み/変更されたフィールドが楽観ロッキングに使用されることを意味します。
- version-column: この要素は、バージョンカラムストラテジーに基づく楽観ロッキングであることを指定します。この要素を指定すると、楽観ロッキング用にエンティティ bean に
java.lang.Longタイプの追加のバージョンフィールドが追加されます。エンティティの更新ごとに、このフィールドの値が増えます。field-name要素は、CMP フィールドの名前の指定を可能にするものであるのに対し、column-name要素は、対応するテーブルのカラム指定ができるようになります。 - timestamp-column: この要素は、タイムスタンプのカラムストラテジーに基づく楽観ロッキングであることを指定します。この要素を指定すると、楽観ロッキング用にエンティティ bean に
java.util.Dateタイプのバージョンフィールドが別途追加されます。エンティティの更新ごとに、このフィールドの値を現在時刻に設定します。field-name要素は、CMP フィールドの名前の指定を可能にするものであるのに対し、column-name要素は、対応するテーブルのカラム指定ができるようになります。 - key-generator-factory:この要素は、キー生成に基づく楽観ロッキングであることを指定します。この要素の値は、
org.jboss.ejb.plugins.keygenerator.KeyGeneratorFactory実装の JNDI 名です。この要素を指定すると、楽観ロッキング用にエンティティ bean にバージョンフィールドが別途追加されます。フィールドのタイプはfield-type要素で指定しなければなりません。エンティティの更新ごとに、キージェネレーターから新しい値を取得することでキーフィールドを更新します。field-name要素は、CMP フィールドの名前の指定を可能にするものであるのに対し、column-name要素は、対応するテーブルのカラム指定を可能にします。
jbosscmp-jdbc.xml 記述子のサンプルを次に示します。
30.11. エンティティコマンドおよびプライマリキー生成 リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml 記述子の entity-command 要素で指定します。デフォルトの entity-command は、jbosscmp-jdbc.xml の defaults 要素で指定できます。それぞれの entity 要素では、 独自の entity-commandを指定することによって、デフォルトの entity-commandをオーバーライドすることができます。entity-commandおよび子要素のコンテンツモデルを次に示します。
図30.15 jbosscmp-jdbc.xml entity-command 要素モデル
entity-command 要素では、エンティティ生成実装を指定します。name 属性では、entity-commands セクションで定義されたコマンドを defaults および entity 要素で参照できるようにする名前を指定します。class 属性では、キー生成をサポートする org.jboss.ejb.plugins.cmp.jdbc 実装を指定します。データベースベンダー固有のコマンドは通常、挿入実行の副次的結果としてデータベースがプライマリキーを生成する場合は org.jboss.ejb.plugins.cmp.jdbc。JDBCIdentityColumnCreateCommand を、生成されたキーをコマンドで挿入しなければならない場合は org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand をサブクラス化します。
attribute 属性は、エンティティコマンド実装クラスに対して利用可能になる任意名/値プロパティペアの指定を可能にするものです。attribute 属性には、名前プロパティを指定する必須の name 属性があり、attribute 属性のコンテンツはプロパティの値です。属性値は、org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityCommandMetaData.getAttribute(文字列) メソッドを使いアクセスすることができます。
30.11.1. 既存のエンティティコマンド リンクのコピーリンクがクリップボードにコピーされました!
standardjbosscmp-jdbc.xml 記述子内にある現行の entity-command 定義です。
- default: (
org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand)JDBCCreateEntityCommandは、standardjbosscmp-jdbc.xmldefaults 要素で参照されるentity-commandであるため、デフォルトの要素作成になります。この entity-command は、割り当てられたプライマリキー値を使用してINSERT INTOクエリーを実行します。 - no-select-before-insert: (
org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand) これは、jboss.jdbc:service=SQLExceptionProcessorサービスをポイントする属性name="SQLExceptionProcessor"を指定することによって insert の select をスキップするdefaultの変化形です。SQLExceptionProcessorサービスは、boolean isDuplicateKey(SQLException e)操作を提供し、一意制約違反がないか判断することができるようになります。 - pk-sql (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCPkSqlCreateCommand)JDBCPkSqlCreateCommandは、pk-sql属性により与えられるINSERT INTOクエリーステートメントを実行して、 次のプライマリキー値を取得します。 シーケンスサポートのあるデータベースが主要な使用目的です。 - mysql-get-generated-keys: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCMySQLCreateCommand)JDBCMySQLCreateCommandは、 MySQL ネイティブjava.sql.Statementインターフェース実装からgetGeneratedKeysメソッドを使用してINSERT INTOクエリーを実行し生成されたキーをフェッチします。 - oracle-sequence: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCOracleCreateCommand)JDBCOracleCreateCommandは、RETURNING句とともにシーケンスを使用して単一のステートメントでキーを生成する、Oracle と併用する作成コマンドです。これには、シーケンスのカラム名を指定する必須のsequence要素があります。 - hsqldb-fetch-key: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCHsqldbCreateCommand)JDBCHsqldbCreateCommandは、CALL IDENTITY()ステートメントの実行後にINSERT INTOクエリーを実行して生成されたキーをフェッチします。 - sybase-fetch-key: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCSybaseCreateCommand)JDBCSybaseCreateCommandは、SELECT @@IDENTITYステートメントの実行後にINSERTINTO クエリーを実行して生成されたキーをフェッチします。 - mssql-fetch-key: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCSQLServerCreateCommand)IDENTITYカラムからの値を使用する Microsoft SQL Server 用のJDBCSQLServerCreateCommandです。デフォルトでは、SELECT SCOPE_IDENTITY()を使用して、トリガーの影響を減らします。たとえば V7 などのpk-sql属性でオーバーライドできます。 - informix-serial: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCInformixCreateCommand)JDBCInformixCreateCommandは、 Informix ネイティブjava.sql.Statementインターフェース実装からgetSerialメソッドを使用した後でINSERTINTO クエリーを実行して生成されたキーをフェッチします。 - postgresql-fetch-seq: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCPostgreSQLCreateCommand) シーケンスの現在値をフェッチする PostgreSQL 用のJDBCPostgreSQLCreateCommandです。オプションのsequence属性を使用して、シーケンス名を変更することができます。デフォルトはtable_pkColumn_seqです。 - key-generator: (
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCKeyGeneratorCreateCommand)JDBCKeyGeneratorCreateCommandは、key-generator-factoryにより参照されるキージェネレーターからプライマリキーの値を取得した後にINSERT INTOクエリーを実行します。key-generator-factory属性ではorg.jboss.ejb.plugins.keygenerator.KeyGeneratorFactory実装の JNDI バインディングの名前を指定しなければなりません。 - get-generated-keys: (org.jboss.ejb.plugins.cmp.jdbc.jdbc3.JDBCGetGeneratedKeysCreateCommand)
JDBCGetGeneratedKeysCreateCommandは、自動生成されたキーを取り出す機能を持つprepareStatement(String, Statement.RETURN_GENERATED_KEYS)を使用して構築されたステートメントを使用してINSERT INTOクエリーを実行します。生成されたキーは、PreparedStatement.getGeneratedKeysメソッドを呼び出すことによって得られます。これは JDBC3 サポートが必要なため、サポートする JDBC ドライバーがある JDK1.4.1+ でのみ利用可能です。
cmp-field にマッピングされる、hsqldb-fetch-keyentity-command を使用した設定例を次に示します。
cmp-field なしに不明なプライマリキーを使用した別例を次に示します。
30.12. デフォルト リンクのコピーリンクがクリップボードにコピーされました!
standardjbosscmp-jdbc.xml file of the server/<server-name>/conf/ ファイルに定義されています。それぞれのアプリケーションで、jbosscmp-jdbc.xml ファイル内のグローバルデフォルトをオーバーライドすることができます。デフォルトオプションは、設定ファイルの defaults 要素に入っています。コンテンツモデルを次に示します。
図30.16 jbosscmp-jdbc.xml defaults コンテンツモデル
30.12.1. jbosscmp-jdbc.xml defaults 宣言例 リンクのコピーリンクがクリップボードにコピーされました!
- datasource: このオプションの要素は、データソースのルックアップに使用される jndi-name になります。エンティティまたは
relation-tableで使用されるデータベース接続はすべてデータソースから得られます。エンティティにさまざまなデータソースを持たせると、finder および ejbSelect でクエリーできるドメインを大きく制約することになるため推奨しません。 - datasource-mapping: このオプションの要素は、Java タイプを SQL タイプにマッピングする方法、および EJB-QL 関数をデータベース固有の関数にマッピングする方法を決める
type-mappingの名前を指定します。タイプマッピングについては、「マッピング」で説明しています。 - create-table: この任意要素が true の場合、JBoss はエンティティのテーブルの作成を試行しなければなりません。アプリケーションがデプロイされると、JBoss は、テーブル作成の前にすでにテーブルが存在しているかどうか確認します。テーブルが見つかった場合は、ログに記録が取られ、テーブルは作成されません。このオプションは、開発の初期段階でテーブル構造が頻繁に変わる場合に非常に役立ちます。デフォルトは false です。
- alter-table: スキーマの自動作成に
create-tableが使用される場合、alter-tableを使ってエンティティ bean に対する変更を反映しスキーマを最新状態に保つことができます。Alter table は次のような特定のタスクを実行します。- 新しいフィールドが作成されます。
- 使用されなくなったフィールドが削除されます。
- 宣言されている長さより短い文字列フィールドは宣言されている長さまで延長されます(すべてのデータベースでサポートされているわけではありません)。
- remove-table:この任意の要素が true の場合、JBoss は、各エンティティおよびリレーションシップにマッピングした各関連テーブルに対して、テーブルのドロップを試行します。アプリケーションのデプロイが解除されたときに、JBoss はテーブルのドロップを試行します。このオプションは、開発の初期段階でテーブル構造が頻繁に変わる場合に非常に役立ちます。デフォルトは false です。
- read-only: この任意の要素は、true の場合、bean プロバイダーがフィールドの値を変更ができなくなります。読み取り専用のフィールドは、データベースに格納もしくは挿入されません。プライマリキーフィールドが読み取り専用である場合、create メソッドは
CreateExceptionを送出します。read-onlyフィールドで set アクセッサーが呼び出されると、EJBExceptionをスローします。読み取り専用フィールドは、最終更新など、データベーストリガーによって入力されるフィールドで役立ちます。read-onlyオプションは、フィールドごとにオーバーライドすることが可能です。デフォルトは false です。 - read-time-out:この任意の要素では、読み取り専用フィールドで読み取りが有効である時間をミリ秒単位で表します。値が 0 の場合にはトランザクション開始時に必ずその値が再読み込みされ、値が -1 の場合には値はタイムアウトしません。このオプションも、CMP フィールドごとにオーバーライドすることが可能です。
read-onlyが false の場合、この値は無視されます。デフォルトは -1 です。 - row-locking: この任意の要素が true の場合、トランザクションでロードされたすべての行を JBoss がロックすることを指定します。ほとんどのデータベースがエンティティのロード時に
SELECT FOR UPDATE構文を使用してこれを実装しますが、実際の構文は、このエンティティで使用されるdatasource-mapping内のrow-locking-templateで決まります。デフォルトは false です。 - pk-constraint: この任意の要素では、true の場合テーブル作成時に JBoss がプライマリキー制約を追加することを指定します。デフォルトは false です。
- preferred-relation-mapping: この任意の要素は、リレーションシップに対する希望のマッピングスタイルを指定します。
preferred-relation-mapping要素は、foreign-keyまたはrelation-tableのいずれかでなければなりません。 - read-ahead: この任意の要素はエンティティの CMR フィールドおよびクエリ結果のキャッシュ化を制御します。このオプションについては 「Read-ahead」で説明します。
- list-cache-max:この任意の要素は、このエンティティで追跡できる
read-listsの数を指定します。このオプションについては、「on-load」で説明しています。デフォルトは 1000 です。 - clean-read-ahead-on-load: 先行読み込み (read ahead) キャッシュからエンティティがロードされる場合、 JBoss は先行読み込みキャッシュから使用されるデータを削除することができます。デフォルトは
falseになります。 - fetch-size:この任意の要素は、基盤データストアへの 1 往復で読み込むエンティティの数を指定します。デフォルトは 0 です。
- unknown-pk: この任意の要素によって、
java.lang.Objectの未知のプライマリキータイプを永続ストアにマッピングする方法を定義することができます。 - entity-command: この任意の要素によって、エンティティ作成用のデフォルトコマンドを定義することができます。これについては、「エンティティコマンドおよびプライマリキー生成」 で詳しく説明しています。
- ql-compiler: この任意の要素によって、代わりのクエリーコンパイラーを指定することができます。代わりのクエリーコンパイラについては、「EJBQL 2.1 と SQL92 のクエリ」で説明しています。
- throw-runtime-exceptions: この属性では、true に設定された場合、データベースへの接続エラーは、チェック例外としてではなく、ランタイム
EJBExceptionとして表示されるべきであることを示します。
30.13. データソースのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
30.13.1. タイプマッピング リンクのコピーリンクがクリップボードにコピーされました!
jbosscmp-jdbc.xml 記述子の type-mapping セクションで行います。type-mapping 要素のコンテンツモデルは、図30.17「jbosscmp-jdbc type-mapping 要素のコンテンツモデル」 に示してあります。
図30.17 jbosscmp-jdbc type-mapping 要素のコンテンツモデル
- name: この必須の要素は、データベースのカスタマイズを識別する名前を指定します。これは、defaults およびエンティティ内に見られる
datasource-mapping要素によるマッピングを参照するのに使用されます。 - row-locking-template: この必須の要素により、選択された行で行ロックを作成するのに使用する
PreparedStatementテンプレートが与えられます。テンプレートは、次の 3 つの引数をサポートしなければなりません。- select 句
- from 句。テーブルの順序は、現在のところ対応していません。
- where 句
select ステートメントで行レベルのロッキングがサポートされない場合は、この要素を空にしなければなりません。行レベルのロッキングの最も一般的な形式は、たとえばSELECT ?1 FROM ?2 WHERE ?3 FOR UPDATEなどのような select for update です。 - pk-constraint-template: この必須の要素は、create table ステートメントにおいてプライマリキー制約を作成するのに使用する
PreparedStatementテンプレートを渡します。このテンプレートは、次の 2 つの引数をサポートしなければなりません。- プライマリキー制約名。これは常に
pk_{table-name}です。 - コンマで区切ったプライマリキー列名のリスト
create table ステートメントでプライマリキー制約句がサポートされない場合は、この要素を空にしなければなりません。プライマリキー制約の最も一般的な形式はCONSTRAINT ?1 PRIMARY KEY (?2)です。 - fk-constraint-template: これは、別のステートメントで外部キー制約を作成するのに使用するテンプレートです。テンプレートは、次の 5 つの引数をサポートしなければなりません。
- テーブル名
- 外部キー制約名。これは常に
fk_{table-name}_{cmr-field-name}です。 - コンマで区切った外部キー列名のリスト
- 参照テーブル名
- コンマで区切った参照プライマリキーカラム名のリスト
データソースが外部キー制約をサポートしない場合は、この要素を空にしなければなりません。外部キー制約の最も一般的な形式はALTER TABLE ?1 ADD CONSTRAINT ?2 FOREIGN KEY (?3) REFERENCES ?4 (?5)です。 - auto-increment-template: これは、自動インクリメントカラムを指定するための SQL テンプレートを宣言します。
- add-column-template:
alter-tableが true であるとき、この SQL テンプレートは、既存のテーブルに列を追加するための構文を指定します。デフォルト値はALTER TABLE ?1 ADD ?2 ?3です。各パラメーターは次のとおりです。- テーブル名
- カラム名
- カラムタイプ
- alter-column-template:
alter-tableが true であるとき、この SQL テンプレートは、既存のテーブルから列をドロップするための構文を指定します。デフォルト値はALTER TABLE ?1 ALTER ?2 TYPE ?3です。各パラメーターは次のとおりです。- テーブル名
- カラム名
- カラムタイプ
- drop-column-template:
alter-tableが true であるとき、この SQL テンプレートは、既存のテーブルからカラムをドロップするための構文を指定します。デフォルト値はALTER TABLE ?1 DROP ?2です。各パラメーターは次のとおりです。- テーブル名
- カラム名
- alias-header-prefix:この必須の要素により、エイリアスヘッダーの作成に使用する接頭辞が付与されます。エイリアスヘッダーは、EJB-QL コンパイラーにより生成されるテーブルエイリアスの先頭に付けられ、名前の重複を防ぎます。エイリアスヘッダーは alias-header-prefix + int_counter + alias-header-suffix のように構成されます。エイリアスヘッダーの例は、alias-header-prefix が "
t" 、alias-header-suffix が "_"の場合でt0_になります。 - alias-header-suffix: この必須の要素により、生成されるエイリアスヘッダーの接尾辞部分が付与されます。
- alias-max-length: この必須の要素により、生成されるエイリアスヘッダーの最大許容長が渡されます。
- subquery-supported: この必須の要素は、この
type-mappingサブクエリーを true とするか false とするかを指定します。一部の EJB-QL 演算子は既存のサブクエリーにマッピングされます。subquery-supportedが false の場合、EJB-QL コンパイラーは left join を使用し、null になります。 - true-mapping: この必須の要素は、EJB-QL クエリーにおける true の識別を定義します。例としては、
TRUE、1、(1=1)があります。 - false-mapping: この必須の要素は、EJB-QL クエリーにおける false の識別を定義します。例としては、
FALSE、0、(1=0)があります。 - function-mapping: この任意の要素は、EJB-QL 関数から SQL 実装へのマッピングを 1 つ以上指定します。詳しくは「関数マッピング」 を参照してください。
- mapping: この必須の要素は、Java タイプから対応する JDBC および SQL タイプへのマッピングを指定します。詳しくは 「マッピング」 を参照してください。
30.13.2. 関数マッピング リンクのコピーリンクがクリップボードにコピーされました!
図30.18 jbosscmp-jdbc function-mapping 要素コンテンツモデル
- function-name: この必須の要素は、
concat、substringなどの EJB-QL 関数名を渡します。 - function-sql: この必須の要素は、基盤データベースに適した関数用の SQL を渡します。concat 関数の例としては、
(?1 || ?2)、concat(?1, ?2)、(?1 + ?2)があります。
30.13.3. マッピング リンクのコピーリンクがクリップボードにコピーされました!
type-mapping とは、マッピングする Java クラスタイプとデータベースタイプ間のマッピングセットのことです。タイプマッピングはmapping 要素により定義されます。このコンテンツモデルについては、図30.19「jbosscmp-jdbc マッピング要素のコンテンツモデル」で紹介しています。
図30.19 jbosscmp-jdbc マッピング要素のコンテンツモデル
java.lang.Object マッピングを使用します。次に、マッピング要素の 3 つの子要素について説明します。
- java-type: この必須の要素は、Java クラスの完全修飾名を渡しマッピングします。クラスが
java.lang.Shortなどのプリミティブラッパークラスである場合、マッピングもプリミティブタイプに適用します。 - jdbc-type: この必須の要素により、JDBC
PreparedStatementでのパラメーターの設定時または JDBCResultSetからのデータのロード時に使用する JDBC タイプが与えられます。有効なタイプはjava.sql.Typesに定義されます。 - sql-type: この必須の要素により、create table ステートメントで使用する SQL タイプが与えられます。データベースベンダーのみが有効なタイプに制限を加えます。
- param-setter: この任意の要素は、このマッピングの
JDBCParameterSetter実装の完全修飾名を指定します。 - result-reader: この任意の要素は、このマッピングに対し
JDBCResultSetReader実装の完全修飾名を指定します。
30.13.4. ユーザータイプマッピング リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb.plugins.cmp.jdbc.Mapper インターフェースのインスタンスを指定することで JDBC カラムタイプからカスタム CMP フィールドタイプへのマッピングを可能にします。その定義を次に示します。
user-type-mappings 要素のコンテンツモデルは、1 つ以上の user-type-mapping 要素から成ります。このコンテンツモデルは図30.20「user-type-mapping コンテンツモデル」に示してあります。
図30.20 user-type-mapping コンテンツモデル
- java-type: マッピングにおける CMP フィールドタイプの完全修飾名。
- mapped-type:マッピングにおけるデータベースタイプの完全修飾名。
- mapper:
java-typeとmapped-type間の変換を処理するMapperインターフェース実装の完全修飾名。
パート IV. パフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
第31章 JBoss Enterprise Application Platform 5 のパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
31.1. はじめに リンクのコピーリンクがクリップボードにコピーされました!
31.2. ハードウェアチューニング リンクのコピーリンクがクリップボードにコピーされました!
31.2.1. CPU (Central Processing Unit: 中央処理装置) リンクのコピーリンクがクリップボードにコピーされました!
- 命令を受信し、受信した命令の種類を判定する制御ユニット。
- 中間の処理情報を一時的に格納する CPU レジスター。
- 後続の実行可能タスクの場所を保持するプログラムカウンター
- 現在実行しているタスクを格納する命令レジスター
- CPU が現在処理しているデータを保持する制限されたメモリである CPU キャッシュ。
31.2.2. RAM (Random Access Memory: ランダムアクセスメモリ) リンクのコピーリンクがクリップボードにコピーされました!
31.2.3. ハードディスク リンクのコピーリンクがクリップボードにコピーされました!
31.3. オペレーティングシステムのパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
top と ps が使用されます。 Red Hat Enterprise Linux や Fedora などの Linux ディストリビューションは、 システムパフォーマンスの監視に便利なグラフィカルユーザーインターフェース System Monitor を提供します。
31.3.1. ネットワーキング リンクのコピーリンクがクリップボードにコピーされました!
31.4. JVM のチューニング リンクのコピーリンクがクリップボードにコピーされました!
31.5. アプリケーションのチューニング リンクのコピーリンクがクリップボードにコピーされました!
注記
31.5.1. インストルメンテーション リンクのコピーリンクがクリップボードにコピーされました!
31.6. JBoss Enterprise Application Platform のチューニング リンクのコピーリンクがクリップボードにコピーされました!
31.6.1. メモリ使用率 リンクのコピーリンクがクリップボードにコピーされました!
-server スイッチのデフォルトは 64 メガバイトです。
-XX:MaxPermSize=256m
-XX:MaxPermSize=256m
-XX:MaxPermSize?=256m -Xmx512m (システムから割り当てられた合計768 メガバイトです。 VM の合計サイズではなく、 VM が 「C ヒープ」 やスタック領域に割り当てる領域は含まれていません。)
31.6.1.1. VFS チューニング リンクのコピーリンクがクリップボードにコピーされました!
VFSUtils クラスにあります。 このストリング定数は、 VFS 動作の設定に使用できる異なるシステムプロパティ設定を示します。
- jboss.vfs.forceCopyネストされた jar の処理方法を定義します。forceCopy が true の場合 (デフォルト)、ネストされた jar の一時コピーを作成し、それに応じて VFS を再配線します。forceCopy が false の場合、 メモリ内でネストされた jar を処理します。 この場合、一時コピーは作成されませんが、より多くのメモリが消費されます。
- jboss.vfs.forceNoReaper は true と false のオプションがあり、デフォルトは false になります。パフォーマンスを向上するため、 別の reaper スレッドより非同期的に JAR ファイルを閉じます。 JAR ファイルを同期的に閉じたい場合は、 reaper スレッドを使用しないよう強制することができます。 URI クエリと
noReaperクエリセクションを使用して定義することもできます。 - jboss.vfs.forceCaseSensitive は true と false のオプションがあり、デフォルトは false になります。有効にすると、 ファイルパスの小文字と大文字を区別するよう強制できます。
- jboss.vfs.optimizeForMemory は true と false のオプションがあり、デフォルトは false になります。有効にすると、 メモリ内の JAR 処理を再命令するため、 メモリ消費が増加します。
- 既存の一時ファイルを再使用するため (展開やワイヤリングを再実行しないようにするため)
jboss.vfs.cache(org.jboss.virtual.spi.cache.helpers.NoopVFSCache) クラスを定義することができます。 VFS レジストリはこのクラスの定義を使用して既存の VFS ルートを維持します。VFS クラスからのVirtualFileルックアップはこのsingletonキャッシュインスタンスを使用して既存の一致するキャッシュエントリを確認します。 一致することで、VirtualFileインスタンスの展開に使用できる既存の「先祖」も考慮します。
31.6.1.1.1. VFS キャッシュのチューニング リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.virtual.spi.cache.helpers.NoopVFSCache が使用されるため、 デフォルトではキャッシングは関係ありませんが、 独自の実装を提供するか、既存の VFS 実装を選択することができます。
org.jboss.virtual.plugins.cache パッケージのキャッシュ実装は次の通りです。
SoftRefVFSCache: マップのエントリ値としてソフト参照を使用します。WeakRefVFSCache: マップのエントリ値として弱参照を使用します。TimedVFSCache: defaultLifetime 後にキャッシュエントリをエビクトします。LRUVFSCache: LRU を基にキャッシュエントリをエビクトし 最小エントリと最大エントリを維持します。CombinedVFSCache: 少数の永久ルートを保持し、 他の新しいルートは realCache プロパティにキャッシュされます。
CombinedVFSCache を使用します。 MC の Bean 設定ファイルで設定する方法は次の通りです。
deploy ディレクトリなど) はこの設定に追加しなければなりません。
31.6.1.1.2. アノテーションスキャンのチューニング リンクのコピーリンクがクリップボードにコピーされました!
- XML またはプログラムにて
ScanningMetaDataを提供します。 deployers/metadata-deployer-jboss-beansのGenScanDeployerBean に新しいデプロイメントフィルターを追加します。deployers/metadata-deployer-jboss-beansのJBossCustomDeployDUFilterを変更します。
META-INF ディレクトリにある jboss-scanning.xml ファイルから取得することもできます。 このファイルの簡単な例は次の通りです。
<scanning xmlns="urn:jboss:scanning:1.0"> <!-- Purpose: Disable scanning for annotations in contained deployment. --> </scanning>
<scanning xmlns="urn:jboss:scanning:1.0">
<!-- Purpose: Disable scanning for annotations in contained deployment. -->
</scanning>
jboss-classloading.xml ファイルに適切なメタデータを提供しスキャンを制限する方法もあります。詳細は、 『JBoss Microcontainer User Guide』 のクラスローディング層の章を参照してください。
31.6.2. データベース接続 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/$PROFILE/deploy/
$JBOSS_HOME/server/$PROFILE/deploy/
<yourdatabasename>-ds.xml
<yourdatabasename>-ds.xml
注記
-ds.xml でないと JBoss Enterprise Application Platform はデータソースファイルとして認識しません。 例えば、 PostgreSQL データベースのデータソースファイルの名前は postgres-ds.xml とします。
注記
<JBoss_Home>/docs/examples/jca ディレクトリにあります。
31.6.3. クラスタリングのチューニング リンクのコピーリンクがクリップボードにコピーされました!
31.6.3.1. 十分なネットワークバッファーの確保 リンクのコピーリンクがクリップボードにコピーされました!
/etc/sysctl.conf ファイルを編集してバッファーサイズの最大値を設定し、 マシンの再起動後も設定を維持するようにします。
# Allow a 25MB UDP receive buffer for JGroups net.core.rmem_max = 26214400 # Allow a 1MB UDP send buffer for JGroups net.core.wmem_max = 1048576
# Allow a 25MB UDP receive buffer for JGroups
net.core.rmem_max = 26214400
# Allow a 1MB UDP send buffer for JGroups
net.core.wmem_max = 1048576
31.6.3.2. クラスター間トラフィックの分離 リンクのコピーリンクがクリップボードにコピーされました!
./run.sh -c all -b 10.0.0.104 -Djgroups.bind_addr=192.168.100.104
./run.sh -c all -b 10.0.0.104 -Djgroups.bind_addr=192.168.100.104
-Djgroups.bind_addr 設定が Enterprise Application Platform を指示しています。 -b は他のトラフィックすべてが 10.0.0.104 を使用するよう指定します。
31.6.3.3. JGroups のメッセージバンドリング リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/$PROFILE/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-jboss-beans.xml ファイルを編集します。Web セッションにデフォルトで使用されるキャッシュの例は次のようになります。
field-granularity-session-cache キーを用いて同じファイル内で同じ変更をキャッシュ設定に加えることができます。 EJB3 ステートフルセッションBean では、 sfsb-cache キーを用いて同じファイル内で同じ変更をキャッシュに加えることができます。
注記
udp-async JGroups プロトコルスタックを使用すると、 追加の JGroups トランスポートプロトコルが使用されます。 そのため、 標準の Enterprise Application Platform インストールよりも多くのソケットが開かれます。
31.6.3.4. セッションキャッシュのバディレプリケーションを有効化 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/$PROFILE/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-jboss-beans.xml ファイルを編集します。Web セッションにデフォルトで使用されるキャッシュの例は次の通りです。
field-granularity-session-cache キーを用いて同じファイル内で同じ変更をキャッシュ設定に加えることができます。 EJB3 ステートフルセッションBean では、 sfsb-cache キーを用いて同じファイル内で同じ変更をキャッシュに加えることができます。
31.6.3.5. Web セッションレプリケーションのボリュームを低減 リンクのコピーリンクがクリップボードにコピーされました!
31.6.3.6. EJB3 ステートフルセッション Bean レプリケーションのボリュームを低減 リンクのコピーリンクがクリップボードにコピーされました!
org.jboss.ejb3.cache.Optimized インターフェースを実装すると制御することができます。 詳細は 「EJB 3.0 でのステートフルセッション Bean」を参照してください。
31.6.3.7. JPA/Hibernate の 2 次キャッシングの注意 リンクのコピーリンクがクリップボードにコピーされました!
31.6.3.8. JMX による JGroups の監視 リンクのコピーリンクがクリップボードにコピーされました!
Channel を作成すると、 そのチャンネルに関連する複数の MBean (チャネル自体の MBean と各構成プロトコルの MBean) にて JXM サーバーも登録します。 チャネルのパフォーマンスに関連する動作を監視したいユーザーにとって、 複数の MBean 属性は有用となるでしょう。
- jboss.jgroups:cluster=<cluster_name>,protocol=UDP,type=protocol
- ネットワーク上におけるメッセージ送受信の統計情報や、 受信メッセージをチャネルのプロトコルスタックまで運ぶために使用する 2 つのスレッドプールの動作に関する統計を提供します。送受信率に直接関係する便利な属性には、
MessagesSent、BytesSent、MessagesReceived、BytesReceivedなどがあります。普通の受信メッセージをプロトコルスタックまで運ぶために使用するスレッドプールの動作に関係する便利な属性には、IncomingPoolSizeやIncomingQueueSizeなどがあります。 特別な非順序で帯域外のメッセージをプロトコルスタックまで運ぶために使用するスレッドプールの同等の属性には、OOBPoolSizeやOOBQueueSizeなどがあります。 標準的な JGroups 設定は OOB メッセージのキューを使用しないため、 通常OOBQueueSizeは0となります。 - jboss.jgroups:cluster=<cluster_name>,protocol=UNICAST,type=protocol
- ユニキャスト (ポイントツーポイント) メッセージを無損失で順番に配信するようにするプロトコルの動作に関する統計情報を提供します。
NumRetransmissionsとMessagesSentとの割合を追跡し、 ピアによってメッセージが受信されず再送信が必要となる頻度を確認することができます。NumberOfMessagesInReceiveWindows属性を監視して、 前のシーケンス番号を持つメッセージが受信されるまで受信側ノードで待機しているメッセージ数を追跡することができます。 このメッセージ数が多いと、 メッセージがドロップし、 再送信の必要があることを意味します。 - jboss.jgroups:cluster=<cluster_name>,protocol=NAKACK,type=protocol
- マルチキャスト (ポイントツーマルチポイント) メッセージを無損失で順番に配信するようにするプロトコルの動作に関する統計情報を提供します。
XmitRequestsReceived属性を使用して、 ノードが送信したメッセージの再送信を要求される頻度を追跡します。XmitRequestsSentを使用して、 ノードがメッセージの再送信を要求する必要頻度を追跡します。 - jboss.jgroups:cluster=<cluster_name>,protocol=FC,type=protocol
- 高速のメッセージ送信側によって低速の受信側が圧倒されないようにするプロトコルの動作に関する統計情報を提供します。受信側からのクレジットを待っている間にメッセージの送信を希望するスレッドがブロックするかを監視する有用な属性には、
Blockings、AverageTimeBlocked、TotalTimeBlockedなどがあります。
31.6.4. その他の主な設定 リンクのコピーリンクがクリップボードにコピーされました!
<JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml ファイルなどがあります。
<JBoss_Home>/server/<your_configuration>/conf ディレクトリに jboss-service.xml ファイルがあります。 プールに実行できるスレッドがない場合に動作を定義する設定があります。 デフォルトでは、 呼び出すスレッドがタスクを実行できるようにします。 JMX コンソールよりシステムのキュー深さを監視し、 プールを大きくする必要があるか判断することができます。
default 設定は開発環境では適切ですが、 実稼働環境では適切でないことがあります。 default 設定では、 コンソールのロギングが有効になっています。 コンソールロギングは、 すべてのログメッセージを IDE コンソールビューで表示できるため、 特に IDE 内の開発には適しています。 実稼働環境では、 コンソールロギングは高負荷であるため推奨されません。 必要な場合は、 ロギングの詳細レベルを下げてください。 ログするデータが少ないほど生成される I/O が少なくなるため、 全体的なスループットが向上されます。
パート VI. 添付資料 リンクのコピーリンクがクリップボードにコピーされました!
付録A ベンダー固有のデータソース定義 リンクのコピーリンクがクリップボードにコピーされました!
A.1. デプロイヤーの場所と名前 リンクのコピーリンクがクリップボードにコピーされました!
$JBOSS_HOME/server/default/deploy/ ディレクトリに保存する必要があります。各デプロイヤーのファイルは-ds.xml のプレフィックスを付ける必要があります。例えば、Oracle データソースデプロイヤーは、oracle-ds.xml などの名称が可能です。正しくファイル名がつけられない場合、サーバーで検索されません。
A.2. DB2 リンクのコピーリンクがクリップボードにコピーされました!
例A.1 DB2 Local-XA
$db2_install_dir/java/db2jcc.jar and $db2_install_dir/java/db2jcc_license_cu.jar ファイルを $jboss_install_dir/server/default/lib ディレクトリにコピーします。DB2 バージョン 8.1 以降に含まれている DB2 Universal JDBC ドライバーを使うと、レガシーの CLI ドライバーの一部である db2java.zip ファイルは、通常必要ありません。
例A.2 DB2 XA
$db2_install_dir/java/db2jcc.jar と $db2_install_dir/java/db2jcc_license_cu.jar ファイルを$jboss_install_dir/server/default/lib ディレクトリにコピーします。
db2java.zip ファイルが必要になります。
例A.3 AS/400 上の DB2
例A.4 AS/400 「ネーティブ」での DB2
com.ibm.db2.jdbc.app.DB2Driver となっており、URL サブプロトコルは db2 です。詳細情報については、http://www-03.ibm.com/systems/i/software/toolbox/faqjdbc.html#faqA1 のJDBC FAQKS を参照してください。
ヒント
- このドライバーは、ジョブの CCSID を区別しますが、
CCSID=37で問題なく機能します。 [systemname]は、WRKRDBDIREのエントリを*localのように定義する必要があります。
A.3. Oracle リンクのコピーリンクがクリップボードにコピーされました!
例A.5 Oracle Local-TX Datasource
例A.6 Oracle XA Datasource
例A.7 Enterprise RAC とOracle の Thin JDBC Driver
注記
A.3.1. Oracle 10g JDBC ドライバーの変更 リンクのコピーリンクがクリップボードにコピーされました!
jboss-service.xml ファイルで Pad オプションを有効にする必要がなくなりました。さらに、<no-tx-separate-pool/> も必要なくなっています。
A.3.2. Oracle 10g に対するタイプマッピング リンクのコピーリンクがクリップボードにコピーされました!
例A.8 Oracle9i タイプマッピング
A.3.3. 基盤の Oracle Connection オブジェクトをリトリーブ リンクのコピーリンクがクリップボードにコピーされました!
例A.9 Oracle Connection オブジェクト
A.3.4. Oracle 11g の制限 リンクのコピーリンクがクリップボードにコピーされました!
A.4. Sybase リンクのコピーリンクがクリップボードにコピーされました!
例A.10 Sybase Datasource
A.4.1. Sybase の制限 リンクのコピーリンクがクリップボードにコピーされました!
- トランザクションにおけるDDLステートメント
- Enterprise Platform の中心部分であるHibernateがあると、データベースがトランザクション内でDDLステートメントに対応するか否かをSQLダイアレクトにより決定することができます。Sybase はこれをオーバーライドしません。デフォルトはJDBCメタデータをクエリしDDLがトランザクション内で許可されているか参照します。しかし、Sybaseはこのオプションを使うかのレポートを修正しません。Sybaseは、ロック関連の問題があるため、トランザクションにおけるDDLステートメントの利用を推奨していません。
ddl in tranオプションの有効化あるいは無効化の方法については、Sybase 文書を参照してくdささい。 - Sybase は、値が基盤となるカラムの制限を越えても例外をスローしません。
- Sybase ASE は、Parameterized SQLを利用している場合例外をスローしません。デフォルトでは、
jconn3.jarはParameterized SQLを挿入に使っており、値が基盤カラムの制限を越えても例外はスローされません。例外がスローされないため、Hibernateは挿入が失敗したことを通知できなくなっています。Parameterized SQLの代わりにDynamic Prepare を使うことで、ASEは例外をスローします。Hibernateはこの例外をとらえ、それに従い動作します。このような理由からHibernateの設定ファイルでは、Dynamic prepareパラメーターをtrueに設定してください。<property name="connection.url">jdbc:sybase:Tds:aurum:1503/masterDb?DYNAMIC_PREPARE=true</property>
<property name="connection.url">jdbc:sybase:Tds:aurum:1503/masterDb?DYNAMIC_PREPARE=true</property>Copy to Clipboard Copied! Toggle word wrap Toggle overflow jconn4.jarはデフォルトではDynamic Prepareを利用します。 - SchemaExportは、連鎖トランザクションモードにてストアドプロシージャーを作成できません。
- Sybaseでは、SchemaExport を使い連鎖トランザクションモードにてストアドプロシージャーを作成することができません。この問題の回避策は、以下のコードを新規のストアドプロシージャーの直後に追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
A.5. Microsoft SQL Server リンクのコピーリンクがクリップボードにコピーされました!
pubs データベースにクエリを行うことができます。
/deploy に移動し、ご利用中の Web ブラウザーでhttp://localhost:8080/test/test.jsp に移動します。
例A.11 DataDirect ドライバーを使った Local-TX Datasource
例A.12 Merlia ドライバーを使った Local-TX Datasource
例A.13 Merlia ドライバーを使った XA Datasource
A.5.1. Microsoft JDBC ドライバー リンクのコピーリンクがクリップボードにコピーされました!
- SQL Server 2000 で利用可能な SQL Server 2000 Driver for JDBC Service Pack 3
- SQL 2000 あるいは 2005 のいずれかで利用可能な Microsoft SQL Server 2005 JDBC Driver。このバージョンには様々な修正が含まれており、JBoss Hibernate で認定されています。このドライバーは JDK 5 で動作します。
release.txt を読み、特に、2005 で導入された新規パッケージ名、同じアプリケーションサーバーで両方のドライバーを使った場合に起こり得るコンフリクトなど、これらのドライバーの違いを理解するようにしてください。
例A.14 Microsoft SQL Server 2000 での Local-TX Datasource
例A.15 Microsoft SQL Server 2005 での Local-TX Datasource
例A.16 Microsoft SQL Server 2005 での XA Datasource
A.5.2. JSQL ドライバー リンクのコピーリンクがクリップボードにコピーされました!
例A.17 JSQL ドライバー
A.5.3. jTDS JDBC ドライバー リンクのコピーリンクがクリップボードにコピーされました!
DatabaseMetaData および ResultSetMetaData メソッドすべての実装に対応しています。
例A.18 jTDS Local-TX Datasource
例A.19 jTDS XA Datasource
A.5.4. "Invalid object name 'JMS_SUBSCRIPTIONS' Exception リンクのコピーリンクがクリップボードにコピーされました!
SelectMethod を指定します。
例A.20 JMS_SUBSCRIPTIONS Exception
17:17:57,167 WARN [ServiceController] Problem starting service jboss.mq.destination:name=testTopic,service=Topic
org.jboss.mq.SpyJMSException: Error getting durable subscriptions for topic TOPIC.testTopic; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Invalid object name 'JMS_SUBSCRIPTIONS'.)
at org.jboss.mq.sm.jdbc.JDBCStateManager.getDurableSubscriptionIdsForTopic(JDBCStateManager.java:290)
at org.jboss.mq.server.JMSDestinationManager.addDestination(JMSDestinationManager.java:656)
17:17:57,167 WARN [ServiceController] Problem starting service jboss.mq.destination:name=testTopic,service=Topic
org.jboss.mq.SpyJMSException: Error getting durable subscriptions for topic TOPIC.testTopic; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Invalid object name 'JMS_SUBSCRIPTIONS'.)
at org.jboss.mq.sm.jdbc.JDBCStateManager.getDurableSubscriptionIdsForTopic(JDBCStateManager.java:290)
at org.jboss.mq.server.JMSDestinationManager.addDestination(JMSDestinationManager.java:656)
例A.21 SelectMethod の指定
<connection-url>jdbc:microsoft:sqlserver://localhost:1433;SelectMethod=cursor;DatabaseName=jboss</connection-url>
<connection-url>jdbc:microsoft:sqlserver://localhost:1433;SelectMethod=cursor;DatabaseName=jboss</connection-url>
A.6. MySQL Datasource リンクのコピーリンクがクリップボードにコピーされました!
A.6.1. ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
手順A.1 ドライバーのインストール
- http://www.mysql.com/products/connector/j/ からドライバーをダウンロードします。MySQL のご利用のバージョンに応じてドライバーを選択するようにしてください。
- ドライバーの zip あるいは TAR ファイルを展開し、
.jarを探します。 .jarファイルを$JBOSS_HOME/server/config_name/libに移動します。$JBOSS_HOMEdocs/examples/jca/mysql-ds.xmlというサンプルのデータソースデプロイヤーファイルを$JBOSS_HOME/server/config_name/deploy/にコピーし、テンプレートとして利用します。
MySQL の制限
- ミリ秒およびミクロ秒の測定
- 現在MySQL は、
TIMEおよびTIMESTAMPなどの値をデータベースに返す際ミリ秒およびミクロ秒の測定に対応していません。これらの測定に依存するテストは失敗します。
A.6.2. MySQL Local-TX Datasource リンクのコピーリンクがクリップボードにコピーされました!
例A.22 MySQL Local-TX Datasource
autoReconnect を有効にし、ポート 3306 で localhost にてホストされるデータベースを使います。Transactions サポートが必要でない限り、これは推奨される設定ではありません。
A.6.3. 名前付きパイプを利用した MySQL リンクのコピーリンクがクリップボードにコピーされました!
例A.23 名前付きパイプを利用した MySQL
A.7. PostgreSQL リンクのコピーリンクがクリップボードにコピーされました!
例A.24 PostgreSQL Local-TX Datasource
重要
max_prepared_transactionsがデフォルト値 (0) を使う場合、却下されます。
max_connectionsの値と同等以上のmax_prepared_transactions 値を設定するように推奨しています。
例A.25 PostgreSQL XA Datasource
A.8. Ingres リンクのコピーリンクがクリップボードにコピーされました!
例A.26 Ingres Datasource
付録B ロギング情報とレシピ リンクのコピーリンクがクリップボードにコピーされました!
B.1. ログレベルの説明 リンクのコピーリンクがクリップボードにコピーされました!
| log4j レベル | JDK レベル | 詳細 |
|---|---|---|
| FATAL |
アプリケーションサービスがクラッシュする可能性が高い
| |
| ERROR | SEVERE |
確実に問題が存在する
|
| WARN | WARNING |
問題発生の可能性は高いが、回復する可能性もある
|
| INFO | INFO |
サイズの小さい詳細ロギング。若干影響はあるが問題ではない
|
| DEBUG | FINE |
サイズの小さい詳細ロギング。興味を引く情報でない
|
| FINER |
中サイズの詳細ロギング
| |
| TRACE | FINEST |
サイズの大きい詳細ロギング
|
注記
例B.1 特定のログレベルにログされる情報を制限
B.2. アプリケーション別にログファイルを分類 リンクのコピーリンクがクリップボードにコピーされました!
conf/log4j.xml の配備記述子で行われます。
例B.2 App 1 のログ出力を別ファイルにフィルタリング
例B.3 TCLMCFilter を利用
jboss.logging.filter.TCLMCFilter が含まれており、デプロイメント URL をもとにフィルタリングが可能になります。
B.3. カテゴリ出力のリダイレクト リンクのコピーリンクがクリップボードにコピーされました!
appender-ref をカテゴリに追加します。
例B.4 appender-ref の追加
org.jboss.management の出力はすべて、jsr77.log ファイルに移動します。additivity属性は、出力はルートのカテゴリアペンダまで移動し続けるかどうかを制御します。false の場合、出力はカテゴリが参照するアペンダまでしか行かないようになっています。
付録C 改訂履歴 リンクのコピーリンクがクリップボードにコピーされました!
| 改訂履歴 | |||||||
|---|---|---|---|---|---|---|---|
| 改訂 5.1.2-2.400 | 2013-10-30 | ||||||
| |||||||
| 改訂 5.1.2-2 | 2012-07-18 | ||||||
| |||||||
| 改訂 5.1.2-100 | Thu Dec 8 2011 | ||||||
| |||||||
| 改訂 5.1.1-100 | Mon Jul 18 2011 | ||||||
| |||||||
| 改訂 5.1.0-100 | Thu Sep 23 2010 | ||||||
| |||||||
