2.7.3 DB Connector for Reliable Messaging連携時のコネクションとSQLの運用
Reliable MessagingとDB Connector for Reliable Messagingが連携するときのコネクションとSQLの運用について説明します。
- 〈この項の構成〉
(1) コネクションの共有
DB Connector for Reliable MessagingとReliable Messagingは，共にJDBCコネクションを利用します。同一トランザクション内でJDBCとJMSのアクセスを行う場合は，JDBCコネクションを共有できます。
DB Connector for Reliable MessagingとReliable Messagingの間でコネクションを共有するには，次の条件を満たす必要があります。
-
DB Connector for Reliable MessagingとReliable Messagingが使用するDBが同一であること。
-
Reliable MessagingのRMAssociateJDBCFlagプロパティにtrueが指定されていること。
-
アプリケーションのリソースアダプタリファレンスの解決時に，データソースとキューコネクションファクトリのSession Bean属性ファイル，Entity Bean属性ファイル，WAR属性ファイル，またはMessageDrivenBean属性ファイルの<res-sharing-scope>タグに"Shareable"を指定していること（各属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」を参照してください）。
-
認証情報（ユーザ名，パスワード）が同一であること。
-
認証方法（コンテナ認証またはアプリケーション認証）が同一であること。
-
Reliable MessagingのQueueSessionが，すべてAutoAcknowledgeモードであること（AutoAcknowledgeモード以外のQueueSessionとの間でコネクションを共有しようとすると，論理コネクション（java.sql.Connection, QueueSession）の取得に失敗します）。
コネクション共有の条件を満たさない場合は，別のJDBCコネクションが取得されます。この場合も，トランザクションマネジャでのトランザクション内では最初にトランザクションに参加したJDBCコネクションが常に利用されます。つまり，2番目以降のJDBCコネクションに対する処理も，最初のJDBCコネクションを利用して行われるので注意が必要です。
なお，コネクション共有を利用するかどうかに関係なく，JDBCコネクションはReliable Messagingのコネクションとしてプール管理されます。一方，DB Connector for Reliable Messagingのコネクションはプール管理されません。コネクション取得時にはReliable MessagingのコネクションプールからJDBCコネクションを取得します。
(2) ステートメントキャンセル
DB Connector for Reliable Messagingと連携する場合，実行中のSQL処理が返ってこない状態でトランザクションのタイムアウトが発生すると，ステートメントがキャンセルされます。
Reliable Messagingのステートメントキャンセルで注意する点を次に示します。
-
ステートメントキャンセルは，ユーザがJDBCを利用して行う処理に対してだけ有効です。ユーザがJMS，またはJDBCとJMSとの間でコネクションシェアリングを利用する場合，ステートメントキャンセルはJDBCの処理に対してだけ有効となります。このとき，JMSを通して行われる処理に対しては，ステートメントがキャンセルされません。
-
トランザクションのサポートレベルがXATransactionでDABrokerを利用してHiRDBと接続する場合，ステートメントはキャンセルされません。
(3) 障害調査用SQLの出力
デッドロックやスローダウンなどの障害が発生した場合，発行したSQLが障害の要因となった可能性があります。そこで，発行したSQLをログに出力することによって，障害要因の解析が容易になります。ログに出力されるSQLの情報を障害調査用SQLと呼びます。障害調査用SQLの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を参照してください。
Reliable Messagingの障害調査用SQLの出力で注意する点を次に示します。
-
障害調査用SQLの出力は，ユーザがJDBCを利用して行う処理に対してだけ有効です。ただし，ユーザがリソースアダプタ管理のトランザクション（リソース固有のAPIによって，ユーザが直接トランザクションを管理する方法）でJDBCとJMSとの間でコネクションシェアリングを利用する場合，JMSを通して行われる処理に対しての障害調査用SQLが出力されることがあります。
-
ステートメントキャンセルと障害調査用SQLの出力は，まず障害調査用SQLの出力が実行され，そのあとにステートメントキャンセルが実行されます。
-
障害調査用SQLは，DB Connector for Reliable Messagingの稼働ログ，および性能解析トレースに出力されます。
- DB Connector for Reliable Messagingの稼働ログ
-
<Application Serverのログディレクトリ>\connectors
- 性能解析トレース
-
<Application Serverのインストールディレクトリ>\PRF\spool\utt\prf\PRF_ID\dcopltrc
(4) 軽微な障害時のコネクション再利用
コネクション利用時に発生したエラーが，テーブルの一意性に違反したSQLの発行など軽微な障害の場合，コネクションを再利用します。
Reliable Messagingの軽微な障害時のコネクション再利用で注意する点を次に示します。
-
軽微な障害時のコネクション再利用は，ローカルトランザクションの場合だけ有効です。トランザクションを使用していない，またはトランザクションのサポートレベルがXATransactionの場合，コネクションは破棄されます。
(5) コネクションIDの取得
DB Connector for Reliable Messagingと連携した場合，接続先DBのコネクションIDを取得できます。コネクションIDとは，DBとの接続に使用しているコネクションを一意に識別するための接続情報です。コネクションIDの取得の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」を参照してください。
Reliable MessagingのコネクションIDの取得で注意する点を次に示します。
-
Reliable Messagingは，一つのトランザクション内の場合，アプリケーションは同じDB Connector for Reliable Messagingのコネクションを利用します。そのため，一つのトランザクション内で複数のコネクションを利用しているときにcjlistpoolコマンドを実行すると，同じコネクションIDが二つあるように見えます。