Oracle WebLogic Serverでの分散トランザクションに対するLogging Last Resource最適化

(1)

Oracle WebLogic Server での分散トランザクションに対する

Logging Last Resource 最適化

Tom Barnes Adam Messinger Paul Parkinson Amit Ganesh German Shegalov

Saraswathy Narayan Srinivas Kareenhalli

Oracle Corporation

500 Oracle Parkway

Redwood Shores, CA 94065, USA

{firstname.lastname}@oracle.com

概要

最先端の OLTP システムは、Presumed-Abort（見込み中断）型の 2 フェーズ・コミット（2PC）プロトコルである XA-2PC プロトコルを使用して分散トランザクションを実行しています。XA 仕様では、2PC における 1PC 最適化と読取り専用最適化が提供されていますが、もう 1 つの重要な最適化である Nested 2PC の取扱いがありません。このドキュメントでは、Oracle WebLogic Server（Oracle WLS）における Logging Last Resource（LLR）最適化について説明します。LLR 最適化は、Java Enterprise Edition（EE）環境に合わせて Nested 2PC 最適化を改善したものです。LLR 最適化を利用すると、JDBC データソースとして統合された SQL データベースを含む複数のトランザクション・リソースにまたがる分散トランザクションを実行する際、強制（同期）書込み数と交換メッセージ数を削減できます。この最適化は SPECjAppServer2004（JEE 向けの業界標準ベンチマーク）に加えて、さまざまな内部ベンチマークで検証されています。LLR は、知名度の高い顧客によって高パフォーマンスなミッション・クリティカル・アプリケーションに配置され、成功を収めています。

1. はじめに

トランザクション（コミットやロールバック・コールによって区切られた一連の処理）は、クライアント・アプリケーションと次の性質を保証するトランザクション・リソース（データベースやメッセージング・システムなど）間の ACID コントラクトであると一般には言われています。1）原子性：中断されたトランザクション（コミットされる前に障害が発生した場合、またはユーザーが明示的にロールバックを行って中断した場合）による影響は消去されます。2）一貫性：一貫性制約に違反したトランザクションは、自動的に拒否または中断されます。3）独立性：アプリケーションから見ると、典型的なマルチユーザー配置においてもトランザクションは一度に 1 つしか実行されません。4）永続性（持続性）：コミットされたトランザクションによる状態の変更は、後続のシステム障害に影響されることはありません（必要に応じて再度実行されます）[13]。トランザクションは通常、順次リカバリ・ログを使用して実装されており、 このログには UNDO 情報および REDO 情報や、ハード・ディスクなどの 永続メモリに保存されたコミット・レコードが含まれています。トランザクションのコミット・レコードがログに含まれると、リカバリはトランザクションがコミットされたと認識します。トランザクションに複数のリソース（参加者、文献ではエージェントとも表記）が含まれ、それぞれ別個のリカバリ・ログ（ローカルまたはリモートのいずれかにかかわらず）を持つ場合、一貫性に欠けるサブトランザクション結果が生じることを防ぐため、コミット・プロセス間を調整する必要があります。トランザクションをコーディネートするために、専用リソースを割り当てるか、または参加者の 1 つを選択します。一貫性のないサブトランザクション結果を回避するため、トランザクション・コーディネータ（TC）は 2PC プロトコルを使用してクライアントのコミット・リクエストを実行します。参考文献[2、3、4、 5、13]では、Presume-Nothing、Presumed-Abort、Presumed-Commit と いった 2PC の変形がいくつか取り上げられています。ここでは、現在の OLTP 界の主流を占める XA 標準[12]の実装に選択された Presumed-Abort 2PC（PA2PC）について、簡単に説明します。

1.1 Presumed-Abort 2PC

投票（準備）フェーズ：TC はすべての参加者に対して準備メッセージを送信します。各参加者はサブトランザクションがコミット可能であると判断すると、サブトランザクションをリカバリ可能な状態 にした上で、肯定的な投票（ACK）を返します。特別な準備ログ・レコードが作成され、トランザクション・ログがディスクへ書き込まれると、サブトランザクションのリカバリ可能性が確保されます。この時点でトランザクションはまだコミットされていないので、選択した分離レベルを実現するためにいずれのロックも解除されません。何らかの理由でトランザクションがコミットできる状態にはないと参加者が判断すると、トランザクションは中断され、強制ロギ ングの対象はなくなり（見込み中断）、否定的な投票（NACK）が返 されます。 コミット・フェーズ：すべての参加者が ACK を返すと、TC は現在 のトランザクションのコミット・レコードを強制ロギングし、コミット・メッセージを使用してすべての参加者に通知を送ります。参加者はコミット・メッセージを受信すると、コミット決定を強制ロギングし、ロック（トランザクション分離のためのロック）を解除した上で、TC にコミット・ステータスを送信します。参加者からすべてのコミット・ステータス・メッセージを収集すると、TC はトランザクション情報を破棄できます（ログ・レコードをガベージ・コレクションに解放）。 中断フェーズ：参加者から 1 つでも NACK が返されると、TC は強 制ロギングを実行することなくロールバック・メッセージを送信（見込み中断）します。ロールバック・ステータス・メッセージを待機する必要はありません。n 個の参加者が関与する PA2PC トランザク ションを障害なしで実行するには、合計で 2n+1 回の強制書込みと 4n 個のメッセージが必要になります。コミット/ロールバック・ス テータス・メッセージが必要になるのはコーディネータ側のガベージ・コレクションのみであるため、これらのメッセージは非同期（バッチなど）で送信するか、または次のトランザクション・インスタンスの投票メッセージに付加（ピギーバック）することができ ます。こうすることで、通信時のメッセージ数が 3n まで削減され、 さらに重要なこととして、上記で実施される同期ラウンドトリップ 数は 1 回のみになります。特定の参加者がコーディネータのロール を果たす場合、コーディネータ側で 1 セットのメッセージを節約できます。また、コーディネータ側でトランザクション・コミットを 2 回ロギングする必要はないため、強制書込みが 1 回少なくて済み ます。このように、PA2PC コミットによるオーバーヘッドは 2n 回 の強制書込みと 3（n-1）個のメッセージにまで削減できます[13]。このドキュメントの全体または一部に対する電子的コピーまたはハード・コピーの作成に関して、この告知文と 1 ページ目全体の引用がコピーに含まれており、そのコピーが収益や商業上の利益を目的として作成または配布されない場合に限り、個人の使用や教育目的での使用は無償で許可されています。上記以外の使用法でのこのドキュメントの再版、サーバーへの投稿、再配布に対しては、事前の明確な許可と料金が必要になります。 EDBT 2010、2010 年 3 月 22～26 日、スイス、ローザンヌ。Copyright 2010 ACM 978-1-60558-945-9/10/0003 ...10 米ドル。

(2)

1.2 関連処理

2PC プロトコルには、周知の最適化手法がいくつかあります。次の 2 つの最適化手法は XA 仕様で説明されているものであり、ベンダー側で実装されるべきものです。読取り専用最適化：参加者が"読取り専用"に投票した場合、現在のトランザクションではその参加者に対する更新は行われていないことを意味します。この場合、2 番目のフェーズではこの参加者はスキップされます。 1 フェーズ・コミット（1PC）：TC は、1 つの参加者のみが分散トランザクションにエンリストされている状況を検出し、投票フェーズをスキップします。 Nested 2PC：もう 1 つの興味深い最適化手法は XA 標準に含まれて

おらず、Jim Gray によって最初に提唱されました[2]。Nested 2PC は

ツリー2PC や再帰2PC とも呼ばれています。この手法では、参加者 P1からPnまでの固定線形トポロジが前提になっています。TC は固定されておらず、投票フェーズ中には左から右へと、またコミット・フェーズ中には右から左へと、TC ロールが伝播されます。クライア ントが P1に対して commit_2pc を呼び出すと、続いて P1自体に対して準備メッセージが生成されます。P（擬似コード内の変数 i で指定）i は図 1 に示した簡単なロジックを実行して、ソースとなる Pfromからの 2PC メッセージを処理します。Nested 2PC 最適化を使用したイン スタンスの無障害実行のコストは、2n 回の強制書込みと 2（n-1）個のメッセージになります。

1.3 Java Transaction API

Java Transaction API（JTA）は XA 仕様の Java"版"であり、分散トランザクション・システムに含まれるパーティ（メッセージング・システムやデータベース・システムなどのトランザクション・リソース、アプリケーション・サーバー、トランザクション・クライアント・アプリケーション）と TC 間の標準 Java インタフェースを定義したものです [11] 。 TC には、 JTA インタフェースの javax.transaction.TransactionManager が実装されています。逆に言う と、2PC トランザクションに参加するには、参加者リソースに JTA インタフェース javax.transaction.xa.XAResource を実装します。また、 階層型の 2PC をサポートするには、サード・パーティの TC によっ てエンリストされる javax.transaction.xa.XAResource を TC にも実装し ます。ここからは、JTA 用語のみを使用し、2PC の TC をトランザクション・マネージャ（TM）と呼び、2PC の参加者を（XA）リソースと呼びます。 すべてのトランザクションには Xid と呼ばれる一意の ID が付けられ ており、サブトランザクションまたはブランチ（XA 用語）を表す 構造にエンコードされています（TM の ID を含む）。TM は isSameRM メソッドを使用することで、現在のトランザクションにエンリストしようとするリソースを、すでにエンリストされているリソースと比較できるため、コミット処理中の 2PC の複雑さを軽減し、場合によっては 1PC 最適化にすることができます。TM は、トランザクショ ンのために実行された処理が start(xid)コールと end(xid)コールに よって区切られていることを確認します。これらのコールは通常ブロッキングであるため、それぞれのコールによってトランザクショ ンごとに少なくとも 4n 個のメッセージが追加されます。クライアン トからトランザクションのコミットが要求されると、TM はエンリストされているすべてのリソースに対して最初に準備フェーズを呼び出し、2 番目のフェーズでは返されたステータスに基づいてコミットまたはロールバックを呼び出します。クラッシュが発生した 後は、TM は登録されているすべての XAReresource に問い合わせ、 recover という誤称メソッドを実行して、準備されているがコミット されていない Xid のリスト、いわゆる不確定トランザクションを取 得します。次に、TM は自身に属するすべての Xid をログに照らし てチェックし（別の TM に属する Xid が含まれる場合もあります）、 コミット・エントリがログに含まれる場合はコミット・コールを（再）発行し、含まれない場合は中断をコールします。

1.4 提案

オラクルの提案は、Oracle WebLogic Server で JDBC データソースを介して LLR 最適化（Nested 2PC 最適化を JEE に合わせて改定したもの）を実装することです[8]。このドキュメントでは、第 2 項で関連する WLS コンポーネントについて概説し、第 3 項では LLR 最適化の設計時の考慮事項について説明します。また、第 4 項で通常運用と障害復旧を実装する際の詳細について説明し、第 5 項では標準 JEE ベンチマークで達成されたパフォーマンスを明らかにします。そして、最後に第 6 項で結論を述べます。

2. Oracle WebLogic Server

Oracle WebLogic Server は、標準ベースのミドルウェア製品ファミリーである Oracle Fusion Middleware 11g に含まれる Java アプリケーション・サーバーであり、特に JEE5 仕様の完全実装を提供します。 JEE5 は、サーブレット（Web ベースのアプリケーション向け）、 Enterprise Java Beans（EJB）、Message Driven Bean（MDB）、アプリケーション・クライアント（サーバー・コンテナ外）などのユーザー・アプリケーション・コンポーネントを管理するコンテナと、コンテナがユーザー・アプリケーション・コンポーネントに対して提供するサービスを定義したものです。このようなサービスには、SQL データベースへ接続するための Java Database Connectivity（JDBC）や、信頼性に優れた非同期の Point-to-Point 通信およびパブリッシュ・サブスクライブ通信を実現する Java Messaging Service（JMS）、また 2PC トランザクションを調整する JTA などがあります。通常、ユーザー・アプリケーションがコンテナ・サービスにアクセスするには、アプリケーション・サーバーによって提供された Java Naming Directory Interface（JNDI）が実装されたディレクトリから、関連する API のエントリ・ポイントを検索します。JEE5 の仕様やドキュメントへは、オンラインの参考資料からアクセスできます[10]。

(3)

Oracle WLS では、該当する配置モジュールを使用することで、アプリケーション・コンポーネントに必要な JMS リソースや JDBC リソースを登録します。JMS モジュールを使用すると、(場合によっては XA 対応の)コネクション・ファクトリやメッセージ宛先（キューまたはトピック）などの JMS クライアント・オブジェクトを構成できます。JDBC モジュールでは、SQL データソースや、（場合によっては XA 対応の） JDBC ドライバの名前や JDBC URL などの一連のパラメータの定義が提供されます。JDBC データソースでは、データベース・アクセスとデータベース接続管理機能が提供されます。データソースごとにデータベース接続プールが定義されています。ユーザー・アプリケーションは、JNDI コンテキストでデータソース（java.sql.DataSource）を検索し、データソー スで getConnection()を呼び出すことで、データソースの接続プールから データベース接続を取得します。接続の使用が終了したら、アプリケー ションからできるだけ素早く close()を呼び出します。こうすることで、 データベース接続がプールに戻され、その後の再利用が可能になります。理想的な XA JDBC ドライバを使用した単一リソースの 1PC トランザクションであっても、トランザクションに参加するリソースの数に関係な く、余分なラウンドトリップが発生する XAResource メソッドの start と end を呼び出す必要があるため、一般的にコストが高くなります。 Oracle WLS に同梱されている組込みの JMS プロバイダ（JMS サーバー）では、基盤となるメッセージ永続化メカニズムとしてローカル・ファイル・システムや JDBC データソースを使用できます。 Oracle WLS の JTA 実装は、WLS サーバーごとに 1 つの TM インスタンスを実行する分散サービスで構成されています。1 つのトランザクションが複数の WLS サーバーにまたがる場合（アプリケーションがリモート EJB を起動する場合）、TM によって、グローバル・コーディネータがルート・ノードとなるコーディネータ・ツリーが形成されます。クラッシュからリカバリできるように、それぞれの TM によってトランザクション・ログ内に 2PC トランザクションの永続状態が維持されます。 JMS サーバーと TM を含む、永続性を必要とするすべてのサーバー・インスタンス上の WLS サービスは、単一のトランザクション永続ストアを使用するよう構成されているため、2PC では 1 つのリソースとして認識されます。永続ストアは、ファイル・ストアか、高速書込み用に最適化されたファイルベースの実装、または SQL データベースを利用した JDBC ストアのいずれかになります。高いパフォーマンス要件を抱える顧客では、ファイル・ストアが使用されます。

3. LLR 設計時の考慮事項

Nested 2PC 最適化とは対照的に、LLR ではネスト方式で準備フェーズを順次起動することはしません。これは、全体の待機時間がおお よそ(n-1)(rtt+dst)まで増加するためです。ここで、rtt は 2 つのリソー ス間のラウンドトリップ時間であり、dst はハード・ディスクの平均同期時間になります。Nested 2PC 最適化のこの部分はメッセージ数を減らすためのものであり、高価で細い 30 年前のネットワーク・リンクと頻繁なロールバックを前提としていますが、現在のブロードバンド時代にこれらに遭遇することはありません。しかし、準備フェーズを呼び出すことなく直接コミットするためには、依然とし て 1 つのリソースを選び出す必要があります。TM は、n-1 個のリソー スに対して非同期の準備フェーズを呼び出します。n-1 個の ACK を 受け取った場合、TM は n 番目のリソース（最後のリソース）に対 してコミットを起動します。このコールが成功すると、投票フェー ズ中に準備された n-1 個のリソースに対するコミットを呼び出すかどうかに関するグローバル決定として使用されます。次の点から、JDBC データソースを LLR として選択することが推奨されています。  一般的なシナリオでは、Oracle WLS 内のアプリケーションはローカル JMS サーバーとリモート・データベース・サーバーにアクセスします。このような（サブ）トランザクションは、ローカル TM によって調整されます。コロケーションが使用されているため、2PC メッセージをローカル・リソースに渡す際、ローカル Java メソッドの起動にかかるコストはわずかになります。したがって、JDBC データソース接続が Last Resource として申し分のない候補になります。  JMS メッセージとは対照的に、データ・レコードやプライマリ索引およびセカンダリ索引などのデータベース・データ構造は、頻繁な更新の対象になります。投票フェーズの完了を待たずに 1 フェーズでデータベース・トランザクションをコミットすると、データベース・ロックの時間が大幅に短縮されます。これによって、データベース・トランザクションのスループットが 2 倍以上になる可能性があります。したがって、アプリケーションがリモート JMS サーバーにアクセスしている（かつ、コロケーションの利点が通用しない）場合でも、ユーザーは JDBC データソースを LLR として使用すべきであると言えます。  PA2PC トランザクションに関係するコンポーネントの処理がコミット・フェーズ中に失敗すると、失敗したコンポーネントが再開されるまで、この PA2PC インスタンスの進行が妨げられます。コンポーネント数を減らすことで、失敗したコンポーネントによって実行中のコンポーネントの処理が妨げられるリスクを最小化することができます。LLR 最適化を利用すると、TM はグローバル・トランザクションの結果を直接 LLR にロギングすることで、ローカルの永続ストア・リソースを排除できます。したがって、JTA TM 以外のローカル永続ストアを使用したローカル JEE サービスを必要としないアプリケーションは、LLR 最適化から得る利点が大きくなります。  ACID コントラクトにおいて、2PC が提供しているのは原子性と永続性のみであり、グローバル・トランザクションに対するグローバルな並行性制御（シリアライズ、分離）は実現していません[13]。さらに悪いことに、同じグローバル・トランザクション内の異なるブランチで実施された変更が可視化される順序が規定されていません。LLR ブランチに対する更新は、その他のブランチに対する更新よりも先に可視化される、という部分的な順序を定義することで、LLR はトランザクション内の決定論を追加しています。LLR である JDBC データソースへの更新を実行し、この特定の更新を同じトランザクション内の JMS 宛先に通知するアプリケーションには、通知を受け取ったタイミングで JDBC 更新が可視化されることが保証されています。 JDBC リソースを最後のトランザクション結果として使用するという決定は、もう 1 つの課題を投げかけます。Nested 2PC 最適化は、チェーンに含まれるすべてのリソースがコーディネータとなる能力がある、つまり、トランザクション結果を永続化し、クラッシュ後もプロトコル実行を継続できるという事実に基づいています。しかし、標準の（XA）JDBC ドライバでは、トランザクション結果を記憶するメカニズムが意図的に除外されています。ACID コントラクトによって、データベースはコミットされたトランザクションの更新を維持するよう義務付けられていますが、PA2PC の項で説明したとおり、トランザクション情報はログから削除されます。

(4)

この問題の解決策は、最後のリソースとなるデータソースが接続しているスキーマ内に LLR 表を追加することです。TM が LLR 最適化を実行する場合、トランザクション・コミットをローカル永続ストアに強制ロギングする代わりに、トランザクション ID（XID）のエントリを LLR 表に挿入し、その後ではじめて TM が最後のリソースに対するコミットを開始します。こうすることで、最後のリソースのコミットとグローバル・トランザクション結果のロギングがアトミック処理になることが保証されます（ここから Logging Last Resource という名前が付けられています）（図 2 の commit を参照）。 これにより、TM またはデータベースの処理が失敗した場合でも、両方の処理がいったん通常に戻れば、TM が LLR 表に問い合わせることで実際のトランザクション結果を特定できるようになります。トランザクションの一環としてトランザクション ID を永続化することは、非 XA 設定で ODBC セッションをリカバリ可能にするために使用されてきた方法でもあります[1]。 TM は LLR トランザクションをコミットすると、準備された XA リソースに対してコミット・リクエストを非同期で送信します。未処理のコミット・リクエストに対する応答をすべて受け取ると、 XA-2PC プロトコルは終了します。Oracle WLS の TM は後続のトランザクションの一環として、LLR 表内の終了した 2PC インスタンスのログ・エントリを、遅延してガベージ・コレクションします。 最後のリソース処理に XAResource 機能が活用されていないことが 分かっているため、LLR データソース定義内の XA JDBC ドライバを非 XA バージョンの高速な JDBC ドライバで置換しても差し支え ありません。またこれにより、XAResource の start メソッドと end メソッドに対する高コストなラウンドトリップ・コールが解消されます。

4. LLR 処理の詳細

データソースの配置時またはサーバー起動時に、LLR データソースはデータベース上に表をロードまたは作成します。データソースはこの表を使用して、データベース接続をプールします。この表は、元のデータソース・スキーマ内に作成されます。データベース表が作成またはロードできない場合、サーバーの起動は失敗します。グローバル・トランザクション内で最初に LLR データソースから取得された接続は、トランザクションのコーディネータに対する内部の JDBC 接続を透過的に保持します。任意のサーバー上にある同じ名前のデータソースから取得されたすべての接続に対する後続トランザクション処理はすべて、この単一の内部 JDBC 接続にルーティングされます。図 2 に、Oracle WLS での JTA トランザクションを LLR 向けに変更したものを簡単に示します。通常運用中に LLR リソースを使用すると、LLR がトランザクション（更新）にエンリストされる際に、少 なくとも 1 つのブロッキング・コール start(xid)が省略され、LLR が コミットされる際にもう 1 つのブロッキング・コールである end(xid) が省略されます。LLR に対する準備フェーズを呼び出す代わりに、トランザクションの XID を LLR 表に記録する Insert 文が呼び出されますが、これによって LLR に対する強制ロギングが実行されることはありません。Nested 2PC とは逆に、すべての非 LLR リソースは 2PC を同時に実行します。ただし、すべての非 LLR リソースに対する準備フェーズが完了するまで、LLR のコミットは開始されません。

4.1 LLR 表

各 WLS インスタンスがデータベース上に LLR 表を保持し、これに対して JDBC の LLR データソースはデータベース接続をプールします。これらの表は 2PC のコミット・レコードを保存するために使用されます。複数の LLR データソースが同じ WLS インスタンス上に配置されており、同じデータベース・インスタンスとデータベース・スキーマに接続している場合は、同じ LLR 表を共有します。明示的 に指定されない限り、LLR 表の名前は WL_LLR_<サーバー名>のよ うに自動的に生成されます。

4.2 LLR の障害とリカバリ処理

Oracle WLS の TM はトランザクション障害を次の方法で処理します。 LLRコミットが試行される前に発生した 2PC エラーについて、TM は即座に例外をスローします。LLRのコミット中に発生した 2PC エラーに対しては、レコードが書き込まれている場合、TM はトランザクションをコミットし、レコードが書き込まれていない場合、TM はトランザクションをロールバックします。レコードが書き込まれているかどうか不明な場合は、TM は曖昧なコミット障害の例外をスローし、トランザクション放棄タイムアウトに達するまで、5 秒ごとにトランザクションを完了しようとします。トランザクションが依然として完了されていない場合、TM はトランザクション放棄メッセージをロギングします。サーバーの起動中、TM は LLR リソースを使用してトランザクション 2PC のレコードをデータベースから読み取り、リカバリされた情報を使用して、トランザクションに参加している非 LLR の XA リソース上のすべてのサブトランザクションをコミットします。 LLR リソース内の JDBC 接続が 2PC レコードの挿入中に失敗した場合、TM はこのトランザクションをロールバックします。LLR リソースに含まれる JDBC 接続が LLR トランザクションのコミット中に失敗した場合、トランザクションが 1PC（LLR リソースのみが参加者である場合）と 2PC のいずれであるかによって結果は異なります。 ★★★★★

(5)

図 4：EAStress2004 のセットアップ 1PC のトランザクションである場合、トランザクションはコミットまたはロールバックされるか、または LLR トランザクションの解決の待機を阻止します。トランザクションの結果はアトミックであり、基盤となるデータベースのみで決まります。2PC トランザクションの場合、結果は LLR 表に基づいて決定されます。図 3. SPECjAppServer2004 の世界的な流通ビジネス[9]

4.3 LLR トランザクションのリカバリ

サーバーの起動中に、各 WLS の TM は、サーバーによって調整された未完了のトランザクション（LLR トランザクションを含む）をリカバリする必要があります。各サーバーは、それぞれの LLR データソース向けの LLR データベース表からトランザクション・レコードを読み取ろうとします。サーバーが LLR データベース表にアクセスできないか、リカバリが失敗する場合は、サーバーは起動されません。

5. パフォーマンスの評価

SPECjAppServer2004 ベンチマークで Oracle Fusion Middleware によって達成された最近の世界記録では、LLR データソースが使用されました。SPECjAppServer2004 は、JEE ベースのアプリケーション・サーバーに対するベンチマークであり、対応しているアプリケーション・サーバーによって実装されたすべての主要な JEE テクノロジーを実行するエンド・ツー・エンドのアプリケーションです。使用されたテクノロジーには、サーブレットや JSP を含む Web コンテナ、 EJB コンテナ、EJB 2.0 の Container Managed Persistence、JMS と Message Driven Bean、トランザクション管理、JDBC が含まれます[9]。図 3 は、これらのコンポーネントの相互関係を示したものです。このドキュメントでは、SPECjAppServer2004 ベンチマークの研究用ワークロード（EAStress2004 と呼ばれています）を使用して、LLR のパフォーマンスが評価されました。SPECjAppServer は、Standard Performance Evaluation Corporation （ SPEC ）の商標です。

SPECjAppServer2004 と EAStress2004 を使用したテスト結果や調査結果は、SPEC によるレビューや承認を受けていないため、公開されている SPEC 結果に対する比較やパフォーマンスの推測を実施することはできません[9]。 SPECjAppServer2004 に含まれる 5 つの領域は、販売、製造、供給、顧客、企業です。販売領域には Web ベース・アプリケーションのユーザー・インタフェース・コンポーネントが含まれており、"ビジネス領域"と見なされるその他の領域（製造、供給、顧客、企業）によって提供されるサービスへアクセスするために使用されています。企業内の領域間だけでなく外部のサプライヤや顧客に対して、生産者と消費者の関係が構築されています。実行に使用されたハードウェアは図 4 に示されており、四角い枠がコンピュータ・ノードを表しています。ベンチマーク・ドライバやサプライヤのエミュレータ、および Oracle WLS などの Java コンポーネントは、Oracle JRockit JVM R27.6 によって実行されています。また、ベンチマーク・アプリケーションは Oracle JDBC Driver 11g を使用して、Oracle WLS からデータベースにアクセスします。XA 実行と LLR 実行のそれぞれで、 XA データソースである oracle.jdbc.xa.client.OracleXADatasource と、 oracle.jdbc.OracleDriver によってサポートされた非 XA データソースが使用されました。 EAStress2004 ワークロードは、XA データソースと LLR データソースの両方に対して、注入速度（IR）700 で、開始時間として 10 分間と安定状態で 60 分間実行されます。IR とは、販売領域内にある販売アプリケーションからのビジネス・トランザクション・リクエストが、テスト対象システム（SUT）に注入される速度を指します。表 1 に重要な結果を要約したものを示します。平均のトランザクション応答時間は、LLR 最適化を使用することで劇的に向上しています。 ★★★★★

(6)

★★ 1 時間に及ぶ安定状態での実行中、XA データソースを使用した場合、 DB の CPU 利用率が 80%向上し、MT の CPU は 6%上昇していることが確認されました。データベースへのラウンドトリップは、約 50% 増加しています。MT への I/O 書込みは 80%増加し、I/O サービス時間は安定したままでしたが、ディスク利用率が 30%増加しました。図 5 に、LLR ありと LLR なしの実行におけるリソース利用率のグラフを示します。

6. 結論

このドキュメントでは、JDBC データソース接続を含む、Oracle WLS での XA-2PC に対する LLR 最適化を紹介しました。LLR は JEE のコンテキスト内で元の Nested 2PC を大幅に最適化し、より優れた機能を提供します。これらは Oracle WLS にのみ適用されます。LLR リソースのリカバリ中に障害が発生すると、起動プロセスが失敗します。LLR はクラスタに対応しており、クラスタ内では TC ノードのみが LLR トランザクションの物理 JDBC 接続をホストしており、同じトランザクション内で、別のクラスタ・メンバー上のまったく同じ名前を持つ LLR データソースに対して送信されたリクエストは、コーディネータを介して別のルートで送信されます。LLR ログ・エントリは、ガベージ・コレクションによって自動的に回収されます。ユーザー・コードを何ら変更しなくても済むように、Oracle WLS では透過的な方法で JTA パフォーマンスを向上することに成功しました。LLR 対応として再定義が必要になったのは、デプロイメント・ディスクリプタまたはサーバー側のデータソース定義のみです。ユーザーはそれぞれのアプリケーション配置で、1 つのグローバル・トランザクションに対して 2 つ以上の LLR データソースがエンリストされないようにする必要があります。LLR データソース接続は、ローカル永続ストアの代わりにグローバル・トランザクションの結果をロギングするように、自動的に選択されます。LLR データソースのコミットに成功すると、グローバル・トランザクションがコミットされます。リモート・データソースに対してフェーズを 1 つ減らすと、多くの場合、トランザクション・スループットが 2 倍以上になります。この機能はオラクルの顧客によって、高いパフォーマンス要件を持つミッション・クリティカルなアプリケーションで幅広く使用されており、認定済みの業界ベンチマークへの配置を通じて検証されています。 表 1：IR 700 での EAStess2004 v1.08 の結果サマリー 応答時間(秒) 購入管理参照製造 XA 4.20 2.40 5.40 3.75 LLR 1.50 1.20 1.90 3.00 比較 2.8 倍 2 倍 2.8 倍 1.25 倍

7. 参考資料

[1] Barga, R.、D. Lomet、T. Baby、S. Agrawal：Persistent Client-Server Database Sessions。2000 年 3 月にドイツのコンスタンツで開催された、第 7 回 Extending Database Technology（EDBT）国際会議の議事録より：462-477

[2] Gray, J.：Notes on Data Base Operating Systems。In Advanced Course: Operating Systems, Springer、1978 年：393-481

[3] Lampson, D. および D. Lomet ： A New Presumed Commit Optimization for Two Phase Commit。1993 年にアイルランドのダブリンで開催された第 19 回 Very Large Data Bases 国際会議の議事録より、Morgan Kaufmann、米国カリフォルニア州サンフランシスコ：630-640

[4] Mohan, C.および B. Lindsay：Efficient Commit Protocols for the Tree of Processes Model of Distributed Transactions。1993 年 8 月にカナダのモントリオール州ケベックで開催された第 2 回 ACM SIGACT/SIGOPS Symposium on Principles pf Distributed Computing の議事録より：76-88

[5] Mohan, C.、B. Lindsay、R. Obermark：Transaction Management in the R* Distributed Database Management System 。 ACM Transactions on Database Systems, 11(4)、1986 年 12 月：378-396 [6] Oracle Corp.：Oracle Benchmark Results、

http://www.oracle.com/solutions/performance_scalability/benchmark _results.html

[7] Oracle Corp.：Oracle Fusion Middleware。

http://www.oracle.com/products/middleware/index.html

[8] Oracle Corp.：Programming WebLogic JTA：Logging Last Resource Transaction Optimization。

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jta/llr. html

[9] SPEC：SPECjAppServer2004、 http://www.spec.org/jAppServer2004/

[10] Sun Microsystems：Java EE at a Glance。 http://java.sun.com/javaee/.

[11] Sun Microsystems：Java Transaction API Specification 1.0.1、 http://java.sun.com/javaee/technologies/jta/

[12] The Open Group：Distributed Transaction Processing：The XA Specification。X/Open Company Ltd.、イギリス、1991 年 [13] Weikum, G.および G. Vossen：Transactional Information Systems：

Theory, Algorithms, and the Practice of Concurrency Control and Recovery。Morgan Kaufmann、2001 年米国カリフォルニア州サンフランシスコ