Cosminexus V9 アプリケーションサーバ Cosminexus Reliable Messaging
Reliable MessagingとDB Connector for Reliable Messagingが連携するときのコネクションとSQLの運用について説明します。
DB Connector for Reliable MessagingとReliable Messagingは,共にJDBCコネクションを利用します。同一トランザクション内でJDBCとJMSのアクセスを行う場合は,JDBCコネクションを共有できます。
DB Connector for Reliable MessagingとReliable Messagingの間でコネクションを共有するには,次の条件を満たす必要があります。
コネクション共有の条件を満たさない場合は,別のJDBCコネクションが取得されます。この場合も,トランザクションマネジャでのトランザクション内では最初にトランザクションに参加したJDBCコネクションが常に利用されます。つまり,2番目以降のJDBCコネクションに対する処理も,最初のJDBCコネクションを利用して行われるので注意が必要です。
なお,コネクション共有を利用するかどうかに関係なく,JDBCコネクションはReliable Messagingのコネクションとしてプール管理されます。一方,DB Connector for Reliable Messagingのコネクションはプール管理されません。コネクション取得時にはReliable MessagingのコネクションプールからJDBCコネクションを取得します。
DB Connector for Reliable Messagingと連携する場合,実行中のSQL処理が返ってこない状態でトランザクションのタイムアウトが発生すると,ステートメントがキャンセルされます。
Reliable Messagingのステートメントキャンセルで注意する点を次に示します。
デッドロックやスローダウンなどの障害が発生した場合,発行したSQLが障害の要因となった可能性があります。そこで,発行したSQLをログに出力することによって,障害要因の解析が容易になります。ログに出力されるSQLの情報を障害調査用SQLと呼びます。障害調査用SQLの詳細については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」を参照してください。
Reliable Messagingの障害調査用SQLの出力で注意する点を次に示します。
コネクション利用時に発生したエラーが,テーブルの一意性に違反したSQLの発行など軽微な障害の場合,コネクションを再利用します。
Reliable Messagingの軽微な障害時のコネクション再利用で注意する点を次に示します。
DB Connector for Reliable Messagingと連携した場合,接続先DBのコネクションIDを取得できます。コネクションIDとは,DBとの接続に使用しているコネクションを一意に識別するための接続情報です。コネクションIDの取得の詳細については,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」を参照してください。
Reliable MessagingのコネクションIDの取得で注意する点を次に示します。
Component Containerが提供するReliable Messagingの接続テストを行うには,連携するDB Connector for Reliable Messagingが稼働中であることが前提となります。また,DB Connector for Reliable Messagingの接続テストでは,Reliable MessagingとDB Connector for Reliable Messagingの両方が稼働中であることを前提とします。
接続テストに失敗した場合は,メッセージの内容に応じて要因を取り除いてください。
All Rights Reserved. Copyright (C) 2012, 2015, Hitachi, Ltd.