4 トランザクション・ガードの使用
トランザクション・ガードは、計画済および計画外の停止と重複送信の間に、実行を1回以下にするためにアプリケーションで使用される汎用インフラストラクチャを提供します。アプリケーションでは論理トランザクションIDを使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。
トランザクション・ガードを使用しないと、アプリケーションが停止の後にリプレイ操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。
トランザクション・ガードには次のような利点があります。
-
コミット結果の保持
-
すべてのトランザクションで既知の結果を保証
-
トランザクションの最大1回の実行
この章のトピックは、次のとおりです:
トランザクション・ガードの概要
トランザクション・ガードの主な目的は、障害が発生した場合に最大実行セマンティクスを提供することです。セマンティクスにより、エンド・ユーザーのトランザクションは、時差なしに最大1回実行されるようになります。
現在のアプリケーションでは、サーバーへの通信障害が発生した場合、最終コミット操作の結果を保証されたスケーラブルな方法で判断することは困難です。多くの場合、エンドユーザーは、重複したリクエストの再発行を回避するために特定のステップに従うように要求されます。たとえば、一部のアプリケーションでは、ユーザーに「送信」
ボタンを2回クリックしないように警告します。これは、2回クリックした場合、ユーザーが意図せずに、同じものを2回購入し、2回分の支払いを行うことがあるためです。
トランザクション・ガードがない場合、トランザクションが開始されており、コミットが発行されている場合、クライアントに返送されたコミット・メッセージに永続性がありません。クライアントは、トランザクションがコミットされたかどうかを認識しないまま残されます。トランザクションは、非トランザクション状態が不正確な場合、またはそのトランザクションがすでにコミットされている場合は、有効に再送信できません。コミットの保証または完了情報がない場合、再送信を行うと、トランザクションが複数回、不正な状態のセッションで適用される可能性があります。
前述の問題を制限するためにグローバルXAトランザクションを使用できます。ただし、XA処理に必要なプロトコルに関連するオーバーヘッドがあります。さらに、アプリケーションの継続性などの一部の機能は、XAトランザクションでは使用できません。
WebLogic Serverトランザクション管理は内部的にトランザクション・ガードと統合して、障害時にトランザクションの状態(コミット結果)を判断します。この統合の利点は、複数のリソースを持つグローバル・トランザクションの場合は、ヒューリスティックな例外を減らし、1つのリソースのみの1フェーズ・トランザクションの場合は、システム例外を減らすことです。この統合の実装はWebLogic Serverの内部で行われ、アプリケーション・コードを変更する必要はありません。
トランザクションの完了時に例外が発生した場合、WebLogic Serverはトランザクション・ガードを使用してトランザクション結果を判断します。アプリケーション・コードを変更する必要はありません。
トランザクション・ガードの詳細は、Oracle Databaseガイドのトランザクションに関する項を参照してください。
トランザクション・ガードの有効化
トランザクション・ガードはデータ・ソースおよびデータベース・サービスの両方で構成する必要があります。
WebLogicデータ・ソースのトランザクション・ガードの有効化
weblogic.jdbc.commitOutcomeEnabled
をtrue
に設定することで、データ・ソースでのトランザクション・ガードのサポートを有効にします。
jdbcSR = create(dsname, 'JDBCSystemResource')
jdbcResource = jdbcSR.getJDBCResource()
driverParams = jdbcResource.getJDBCDriverParams()
driverProperties = driverParams.getProperties()
tgprop = driverProperties.createProperty('weblogic.jdbc.commitOutcomeEnabled')
tgprop.setValue('true')
トランザクション・ガードを使用してトランザクションのステータスを取得しようとしている間に、操作がタイムアウトしてトランザクションが失敗する場合があります。トランザクション・タイプがEmulateTwoPhaseCommit、OnePhaseCommitまたはLoggingLastResourceのデータソース上の接続のタイムアウトは、XA completion-timeout値を使用します。トランザクション・タイプが「なし」のデータソース上の接続のタイムアウトは、10秒です。
デフォルト値を無効にするには、weblogic.jdbc.commitOutcomeRetrySeconds connection
プロパティを使用します。たとえば、前述のWLSTスクリプトに次を追加します。
tgseconds = driverProperties.createProperty(
'weblogic.jdbc. commitOutcomeRetrySeconds’)
tgseconds.setValue('60')
ノート:
この機能は、XAリソースおよび非XAリソースまたは複数のEmulateTwoPhaseCommitリソースを持つグローバル・トランザクションでサポートされています。1つ以上の参加リソースを持つグローバル・トランザクションでは、まだヒューリスティックな結果が発生する可能性があります。トランザクション・ガード機能をデータ・ソースで使用しても、このタイプのグローバル・トランザクションの非アトミック/ヒューリスティックな結果に対する固有の潜在的な可能性を防ぐことはできません。データベース・サービスのトランザクション・ガードの有効化
-commit_outcome
パラメータをTRUE
に設定して構成する必要があり、オプションで保持タイムアウトを設定する必要があります。
たとえば:
srvctl modify service -d mydb -s myservice -e TRANSACTION -commit_outcome TRUE -retention 604800 -rlbgoal SERVICE_TIME -clbgoal SHORT
「トランザクション・ガードのデータベース構成」を参照してください
トランザクション・ガードのデータ・ソースの統計
トランザクション・ガードのweblogic.management.runtime.JDBCDataSourceRuntimeMBean
で使用可能なデータ・ソース統計について学習します。
次に示す関連統計は、weblogic.management.runtime.JDBCDataSourceRuntimeMBean
で使用できます。
public long getResolvedAsCommittedTotalCount();
データ・ソースがデプロイされてから、このデータ・ソースでコミット済として正常に解決されたコミット結果の累積合計数です。
public long getResolvedAsNotCommittedTotalCount();
データ・ソースがデプロイされてから、このデータ・ソースでコミット済として正常に解決されたコミット結果の累積合計数です。
public long getUnresolvedTotalCount();
データ・ソースがデプロイされてから、このデータ・ソースで正常に解決されなかったコミット結果の累積合計数です。
public long getCommitOutcomeRetryTotalCount();
データ・ソースがデプロイされてから、このデータソースで結果を解決されたか、再試行秒数を超えるまでに実行されたコミット結果の問合せ再試行の累積合計数です。
「JDBCDataSourceRuntimeMBean」を参照してください。