トランザクション設計 1 WASV6.1による基幹システム設計Workshop

WASV6.1による基幹システム設計Workshop
トランザクション設計
1
Agenda
„
トランザクションの基礎
‹
‹
‹
„
„
WAS V6.1が提供するトランザクション機能概要
トランザクション設計ポイント
‹
‹
‹
‹
„
トランザクションとは
ローカル・トランザクション
分散トランザクション
設計のポイント
アプリケーション設計
障害設計
運用管理設計
Hint & Tips
‹
トランザクションのピア・リカバリー実現のための考慮点
2
当セッションでは、トランザクションをWAS上で実装する際に、重要となる設計ポイントについてご説明さ
せて頂きます。また、昨今のWebシステムではミッションクリティカルな要件が求められており、トランザク
ションの障害設計に重点をおいてご説明させて頂きます。
2
トランザクションの基礎
トランザクション
‡
‡
‡
‡
トランザクションとは
トランザクション処理の必要性
トランザクションの稼動環境
トランザクション・マネージャー
3
3
トランザクションとは
„
ACID属性を維持する必要のある処理
‹Atomicity(原子性)
¾ トランザクションは、一連の操作の最小単位
¾ トランザクションの一部分を実行しても、意味をもたない
‹Consistency(一貫性)
¾ トランザクションでは、データの状態が一貫性を持つ
¾ 常に整合性が取れている必要があり、その為にはアプリ
ケーション開発者が行うべき作業がある
ATM
‹Isolation(分離性)
¾ トランザクションは、独立した作業単位
¾ 並行するトランザクションが存在しても、それぞれのトラン
ザクション内部での処理は、互いに影響しない
‹Durability(持続性)
¾ トランザクションは、回復の処理単位
¾ トランザクションが成功すると、システムに障害が発生して
も、データの更新は持続される
口座振替処理
口座A
DB
口座A
-10,000円
口座B
口座B
+10,000円
Transaction
4
トランザクションとは”取引”という意味になり、問題なく取引を完了させることが重要です。言い換えます
と、トランザクションとは以下のACID属性を維持する必要のある処理になります。
・Atomicity(原子性)
トランザクションは一連の操作の最小単位になります。トランザクションの一部分だけが実行されても意
味がありません。(口座Aからお金が引かれても口座Bにお金が加算されなければ処理が成り立ちませ
ん。)
・Consistency(一貫性)
トランザクションでは、処理の前後でデータの一貫性が保たれなければいけません。(口座Aと口座Bの
合計が、トランザクション処理の前後で異なっていては、処理が成り立ちません。)
・Isolation(分離性)
トランザクションは、独立した作業単位になり、複数のアプリケーションにより並行してトランザクション処
理が実施されていても、その処理がお互いに影響を及ぼさない必要があります。
・Durability(持続性)
トランザクションは回復の処理単位になり、トランザクション処理が正常に終了したら、システムに障害が
発生してもそのデータの更新は持続される必要があります。
4
トランザクション処理の必要性 (1/2)
・トランザクション処理でなければ、原子性を保つことが出来ない
例）口座Aから口座Bへ1万円を送金
1. DBから口座Aの残高を取得(残高=“10万円”)
2. DBから口座Bの残高を取得(残高=“ 5万円”)
3. 口座Aに対して1万円を減分
4. 口座Bに対して1万円を増分
5. DBの口座Aの値を更新(残高=“9万円”)
6. DBの口座Bの値を更新(残高=“6万円”)
1.
銀行口座 DB
2.
口座
3.
A
10万円
9万円
4.
B
5万円
5万円
残高
結果
・トランザクション処理では原子性を保つことが出来る
1. DBから口座Aの残高を取得(残高=“10万円”)
2. DBから口座Bの残高を取得(残高=“ 5万円”)
3. 口座Aに対して1万円を減分
4. 口座Bに対して1万円を増分
5. DBの口座Aの値を更新(残高=“9万円”)
6. DBの口座Bの値を更新(残高=“6万円”)
銀行口座 DB
1.
2.
口座
3.
A
10万円
10万円
4.
B
5万円
5万円
残高
結果
5.Rollback
5
上図は、トランザクション処理でなければ、原子性を保つことが出来ないという例になります。トランザク
ション処理であれば実行結果は、口座A=10万円/口座B=5万円か、口座A=9万円/口座B=6万円のどちら
かになります。
5
トランザクション処理の必要性 (2/2)
・トランザクション処理でなければ、分離性を保つことが出来ない
1. DBから口座Aの残高を取得
2. 口座Aに対して1万円を増分
3. DBの口座Aの値を更新(残高=“2万円”)
1.
3.
銀行口座 DB
5.
2.
1. DBから口座Aの残高を取得
2. 口座Aに対して1万円を1増分
3. DBの口座Aの値を更新(残高=“2万円”)
4.
6.
口座
残高
結果
A
1万円
B
-
2万円
・トランザクション処理では分離性を保つことが出来る
1. DBから口座Aの残高を取得
2. 口座Aに対して1万円を1増分
3. DBの口座Aの値を更新(残高=“2万円”)
1.
2.
銀行口座 DB
3.
4.
1. DBから口座Aの残高を取得
2. 口座Aに対して1万円を増分
3. DBの口座Aの値を更新(残高=“3万円”)
5.
6.
口座
残高
結果
A
1万円
B
-
3万円
6
上図は、トランザクション処理でなければ分離性を保つことが出来ないという例になります。トランザクショ
ン処理であれば実行結果は、口座A=3万円になります。
6
トランザクションの稼働環境
„
複数のミドルウェアの連携によりトランザクション処理を実行
‹
トランザクション・マネージャー
¾
複数のリソースに跨ったトランザクションをコーディネート
WAS、CICS、IMS、WMQ(分散系)、etc.
‹
リソース・マネージャー
¾
データを保持し、参照・更新要求を満たす
DB2、WMQ、IMS、CICS、etc.
トランザクション
マネージャー
リソース
マネージャー
作業単位開始
更新
DB
同期点
7
実際のトランザクションの稼動環境は、WASやMQ、DBなどの複数のミドルウェアによって成り立っていま
す。
＜トランザクション・マネージャー＞
トランザクションの開始/終了/commit/rollbackを実施するなど、トランザクションのコーディネーターの役
割になります。
＜リソース・マネージャー＞
データを保持し、トランザクション・マネージャーやアプリケーションによる参照/更新処理を確実に実施
する役割になります。
7
トランザクション・マネージャー
„
WASがTMとなり、トランザクションを調停
‹
‹
トランザクションの開始/終了はWASで稼動するJavaアプリケーションで実装
キュー・マネージャーとデータベースはリソース・マネージャーとしてトランザクションに
参加
WAS
TM
TM
DB
tx.begin()
DBのテーブルの更新
メッセージの送信
キュー・
マネージャー
tx.commit()
„
キュー・マネージャーがTMとなり、トランザクションを調停
‹
‹
トランザクションの開始/終了はMQのアプリケーションが実装
MQ base Java、Cなど
TM
TM
キュー・
マネージャー
MQBEGIN
メッセージの受信
DBのテーブルの更新
MQCMIT
DB
8
これ以降、当セッションでは、トランザクション・マネージャーをTM、リソース・マネージャーをRMと略させ
て頂きます。
・WASがTMとなりトランザクションを調停する場合
トランザクションの開始/終了/commit/rollbackは、WAS上で稼動するアプリケーションによって実装され
ます。アプリケーションのビジネスロジックとして、DBやキューマネージャーに接続されることにより、DBや
キューマネージャーのRMが、WASのトランザクションに参加します。
・キュー・マネージャーがTMとなり、トランザクションを調停する場合
トランザクションが開始/終了は、MQのアプリケーションによってMQBEGIN/MQCOMMIT等が実行され
る事により、実装されます。その際、MQがTMとなってトランザクションをコーディネートしています。また、
アプリケーションの実装方式は、MQやCなどが考えられます。
8
トランザクションの基礎
ローカル・トランザクション
‡
‡
‡
‡
ローカル・トランザクションとは
リソース・マネージャーのトランザクションの管理
ローカル・トランザクション処理の限界
(参考)ローカル・トランザクション内包(LTC)とは
9
9
ローカル・トランザクションとは
„
１つのリソースを対象としたトランザクション
‹
RMがトランザクション管理機能を提供
DB、MQ
„
1フェーズ・コミット(1PC)
Application
Application
ResourceManager
ResourceManager
トランザクションの開始(begin)
任意の要求(テーブルの検索)
任意の要求(テーブルの更新)
トランザクション確定(commit)
トランザクション確定への応答(committed)
10
RMは、DBやMQなどの1つのリソースを対象にしています。通常は、RM自身もトランザクション管理を
行っており、これをローカルトランザクションと呼んでおります。また、ローカルトランザクションは1つの処理
を対象としている為、1フェーズ・コミット(1PC)とも呼ばれます。
10
リソース・マネージャーのトランザクション管理
„
トランザクション管理にはログを使用
‹
‹
Atomicity(原子性)/Durability(持続性)の保証
障害からの回復
¾
‹
トランザクションが確定されるとログを出力し、障害時には出力したログを参照して回復す
る
ログの種類
¾
z
z
¾
Application
Application
ResourceManager
ResourceManager
更新ログ
Beforeイメージ
Afterイメージ
同期点制御ログ
z
z
Beginログ
Syncpointログ
トランザクションの開始(begin)
任意の要求(テーブルの検索)
任意の要求(テーブルの更新)
トランザクション確定(commit)
Log
トランザクション確定への応答(commited)
11
リソース・マネージャーでは、ACID属性を維持する為、トランザクションが確定されるとその結果をログに
書き出します。障害時には、そのログを参照する事により、問題なく回復する事が出来ます。
11
ローカル・トランザクション処理の限界
„
複数リソースを対象とした処理で、原子性・一貫性を保つことができない
Application
Application
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
トランザクションの開始(begin)
トランザクションの開始(begin)
任意の要求(テーブル1の更新)
任意の要求(テーブル2の更新)
トランザクション確定(commit)
トランザクション確定への応答(committed)
トランザクション確定(commit)
Log
更新成立
更新成立
原子性、一貫性を
原子性、一貫性を
保つことができない
保つことができない
更新不成立
更新不成立
２フェーズ・コミットの登場
２フェーズ・コミットの登場
分散トランザクション処理モデルとして規定
分散トランザクション処理モデルとして規定
12
ローカル・トランザクション処理の場合は、複数リソースを対象にすると、原子性・一貫性を保つことが出
来ないという問題が発生します。この問題を解決する為に、2フェーズ・コミット(2PC)が登場し、この処理モ
デルが分散トランザクション処理モデルとして規定されました。
12
(参考)ローカル・トランザクション内包(LTC)とは
„
ローカル・トランザクションにおける作業単位(UOW)
„
WAS - DB間の接続形態
‹
共有可能接続
¾
connectionをcloseしても直ちにフリープールには戻らない
¾
Servletが終了した段階で、フリープールに戻される
z
‹
共有不可能接続
¾
„
LTC内からの再利用に備えて、DBサーバーと接続を持ったまま待機する
connectionはclose後、 LTCの作業単位(UOW)境界に到達した段階で、フリープー
ルに戻される
共有可能接続の考慮点
‹
close後に時間を要する処理を行っている場合、コネクションをフリー
プールに戻すタイミングが遅れ、システム全体のスループットに影響
を与える可能性があります。
[07/02/03 15:18:59:233 JST] 748a9579 SharedPool I J2CA0086W: リソース jdbc/sampleds からの共用可能接続
MCWrapper id 5c5c1528 Managed connection
com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl@75e6d53f State:STATE_TRAN_WRAPPER_INUSE
がローカル・トランザクション内包境界内で使用されました。
13
ローカル・トランザクション内包(LTC)とは、Local Transaction Containmentの略になり、ローカル・トラン
ザクションにおける作業単位(UOW)になります。トランザクション設計とは少し話がそれますが、WAS-DB
間の接続形態として共有可能接続と共有不可能接続があり、それぞれ以下の挙動となります。
・共有可能接続
connectionをcloseしても直ちにフリープールには戻らず、LTC内からの再利用に備えて、DBサーバーと
接続を持ったまま待機します。そして、LTCの作業単位(UOW)境界まで到達後、フリープールに戻されま
す。
・共有不可能接続
connectionはclose後、直ぐにフリープールに戻されます。
共有可能接続は、再利用時にコネクション属性(分離レベル・読み取り専用属性・カタログ・TypeMap)を
設定し直す必要がないため、パフォーマンスが向上すると言われております。しかし、close後に時間を要
する処理を行っている場合は、コネクションをフリープールに戻すタイミングが遅れ、システム全体のス
ループットに影響を与える可能性がありますので、ご注意下さい。また、LTC内にて共有可能接続を使用
すると、上記のようなメッセージが出力されます。以下のTechNoteが発行されておりますので、共有可能
接続を使用してアプリケーションがハングした場合には、ご確認下さい。
・InfoCenter - 「ローカル・トランザクション内包(LTC)」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/cjta_loctran.html
・Technote – 「Application hangs with prior J2CA0086W warning messages」
http://www-1.ibm.com/support/docview.wss?uid=swg21121449
13
トランザクションの基礎
分散トランザクション
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
分散トランザクション処理モデル
J2EEにおける分散トランザクション処理モデル
(参考)JTA (Java Transaction API)
(参考)javax.transactionパッケージ一覧
2フェーズ・コミット
2フェーズ・コミットの処理フロー
アプリケーションとTMの責任範囲
インダウト・ウィンドウ
ログへの書き込み
グローバル・トランザクションにおける最適化
(参考)READ-ONLYの処理フロー
14
14
分散トランザクション処理モデル
アプリケーション
RM毎のインターフェース
リソース・
マネージャー
(RM)
„
トランザクション・
マネージャー
(TM)
J2EE (JTA : Java Transaction API)は分散トランザクション処理モデルに基づいたト
ランザクション処理をサポート
各コーディネーターによるトランザクションの調停
‹
‹
‹
„
XAインターフェース
(2フェーズ・コミット)
The Open Groupが規定した処理モデル
‹
„
TXインターフェース
(tx_begin()など)
アプリケーション
トランザクション・マネージャー
リソース・マネージャー
2フェーズ・コミット・プロトコル
‹
TM とRM間のトランザクションのコーディネーション・プロトコル
¾
¾
XAインターフェースとして標準化
J2EEでは、javax.transaction.xa.XAResourceインターフェースで規定される
15
分散トランザクション処理モデルとは、The Open Groupが規定した処理モデルになり、J2EEは分散トラン
ザクション・モデルに基づいたトランザクション処理をサポートします。各コーディネーターは、それぞれ以
下の役割があります。
＜アプリケーション＞
TMに対して、TXインターフェースを使用して、トランザクションの開始/終了/commit/rollback等の指示
を行います。
RMに対して、RM毎のインターフェースを使用して、アプリケーションによるDB参照/更新等のビジネスロ
ジックを実施します。
＜トランザクションマネージャー/リソース・マネージャー＞
アプリケーションからのトランザクションの開始/終了/commit/rollback等の指示に対して、TMとRMが協
業し、実際のトランザクション処理をコーディネートします。
TMとRM間の遣り取りにおいて、XAインターフェースが規定されており、その中で2フェーズ・コミット・プ
ロトコルが規定されています。
15
J2EEにおける分散トランザクション処理モデル
J2EE コンポーネント
JDBC, JMS, など
リソース・
マネージャー
(RM)
EJB CMT
JTA
(javax.transaction.xa.XAResource)
JTA
(javax.transaction.UserTransaction)
トランザクション・
マネージャー
(TM)
16
上図は、J2EEにおける分散トランザクションモデルになります。分散処理環境におけるトランザクション処
理モデルと同様になります。
16
(参考)JTA (Java Transaction API)
„
„
分散トランザクションを管理するために必要なTMやRMのインターフェースを規定
X/OpenのXAプロトコルをJavaにマッピングした仕様
‹
‹
‹
„
„
„
TMとRMの間のプロトコル
J2EE環境では、TMとRMの間にResourceAdapterが仲介
ResourceManagerはxa_*コマンドを仲介するために、XAResourceインターフェイスの実装
を提供
TMが管理するトランザクション = グローバル・トランザクション
TMが直接管理しないRM上のトランザクション = ローカル・トランザクション
WASでは、JTAに準拠したTMを提供
17
JTA(Java Transaction API)は、分散トランザクションを管理するために必要なTM やRM のインター
フェースが規定されています。詳細につきましては、以下をご参照下さい。
・Java Transaction API (JTA)
http://java.sun.com/products/jta/
17
(参考)javax.transactionパッケージ一覧
„
package javax.transaction
‹
InterFaces Summary
¾
¾
¾
¾
¾
¾
„
package javax.transaction.xa
‹
InterFaces Summary
¾
¾
„
public interface Status
public interface Synchronization
public interface Transaction
public interface TransactionManager
public interface TransactionSynchronizationRegistry
public interface UserTransaction
public interface XAResource
public void Xid
package javax.transaction.xa.XAResourceインターフェースのメソッド一覧
¾
¾
¾
¾
¾
¾
¾
¾
¾
¾
commit
end
forget
getTransactionTimeout
isSameRM
prepare
recover
rollback
setTransactionTimeout
start
void commit(Xid xid, boolean onePhase)
void end(Xid xid, int flags)
void forget(Xid xid)
int getTransactionTimeout()
boolean isSameRM(XAResource xares)
int prepare(Xid xid)
Xid[ ] recover(int flag)
void rollback(Xid xid)
boolean setTransactionTimeout(int seconds)
void start(Xid xid, int flags)
18
上記は、javax.transactionパッケージ一覧になります。実際に、TMとRM間での遣り取りでは、
XAResourceインターフェースの各メソッド(commit、prepare、rollback等)が実行されています。以降で、2
フェーズ・コミットの処理フローをご説明させて頂きますが、その処理フローでのxa_prepareやxa_commitは
XAResourceインターフェースの各メソッドになります。
18
2フェーズ・コミット
„
„
2フェーズ・コミット・プロトコルとは
‹
TMとRM間のトランザクション調整するプロトコル
‹
複数のRMに跨る更新を一つのUOWとして整合性を保って行うためのプロト
コル
特徴
‹
2つのフェーズから成るトランザクション調停
¾
準備(Prepare)・フェーズ
z
z
¾
TM・・・変更をコミットすることをすべてのRMに対して通知し、同意を取り付ける
RM・・・変更を永続的に保持できる状態にする
コミット(commit)・フェーズ
z
z
TM・・・RMの同意に基づいて、変更をコミットする
RM・・・変更が確定したことをログに書き出し、保持していたロックを開放する
19
2フェーズ・コミット・プロトコルとは、TMとRM間のトランザクションを調整するプロトコルであり、複数のRM
に跨る更新を一つのUOW(UnitOfWork)として、整合性を保って行うためのプロトコルになります。特徴とし
て、以下の2つのフェーズから成るトランザクションをコーディネートします。
・準備(prepare)フェーズ
TM・・・変更をコミットすることをすべてのRMに対して通知し、同意を取り付ける
RM・・・変更を永続的に保持できる状態にする
・コミット(commit)・フェーズ
TM・・・RMの同意に基づいて変更をコミットする
RM・・・変更が確定したことをログに書き出し、保持していたロックを開放する
19
2フェーズ・コミットの処理フロー
„
„
２つのフェーズ「準備フェーズ」と「コミット・フェーズ」に分けて処理を行う
すべてのRMが準備要求に対して正常応答を返した場合のみ、確定要求
を送る
Application
Application
TransactionManager
TransactionManager
トランザクション確定
(commit)
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
トランザクション確定の準備(xa_prepare)
Log
準備フェーズ
トランザクション確定の準備(xa_prepare)
Log
Log
トランザクション確定(xa_commit)
Log
確定フェーズ
トランザクション確定(xa_commit)
Log
20
上図は、2フェーズ・コミットの処理フローになります。
・トランザクション確定(commit)
ApplicationからTMに対して、”トランザクションの確定(commit)”処理が発行され、ここから2フェーズ・コ
ミットの処理フローが開始されます。
＜準備フェーズ＞
・トランザクションの確定の準備(RM1)
TMからRM1に対して、”トランザクションの確定の準備要求(xa_prepare)”処理が発行されます。この時、
RMは、要求に対して準備されているかをログに書込み、処理結果をTMに返答します。
・トランザクションの確定の準備(RM2)
同様に、 TMからRM2に対して、”トランザクションの確定の準備要求(xa_prepare)”処理が発行されます。
この時、RMは、要求に対して準備されているかをログに書込み、処理結果をTMに返答します。また、TM
は、両方のRMから準備されているかの返答をログに書き込みます。両方のRMが準備されている場合
は、”トランザクションの確定(commit)”処理にてcommitされます。両方のRMが準備されていない場合に
は、”トランザクションの確定(xa_commit)”処理にてrollbackされます。更にその時の情報がログに書き込ま
れます。
＜確定フェーズ＞
・トランザクション確定(RM2) / トランザクション確定(RM1)
“トランザクション確定の準備(xa_prepare)”処理にて確定した判断が、それぞれのRMに対して実行され、
一連のトランザクション処理が完了する流れとなります。
20
アプリケーションとTMの責任範囲
„
２フェーズ･コミットはTMに任せましょう
Application
Application
TransactionManager
TransactionManager
トランザクション開始
(begin)
アプリケーションの
責任範囲
※EJBの場合、
コンテナーが実施
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
Log
RM1の更新
Log
Log
RM2の更新
トランザクション確定
(commit)
xa_prepare
xa_ok
Log
準備フェーズ
xa_prepare
Log
xa_ok
TMの責任範囲
Log
xa_commit
xa_ok
Log
確定フェーズ
xa_commit
xa_ok
Log
21
Log
２フェーズ･コミットは、アプリケーションが発行したトランザクション確定（commit）後の処理になります。
トランザクションの開始（begin)と確定(commit)は、JTAを使用して実装されたアプリケーションから行いま
す。そのコマンドを受けて、TMは各RMと通信することで調整を行います。
2フェーズ・コミットの仕組みをすべてアプリケーションで構築するのは非常に負担が大きく、またリソース
の種類が増えれば、それだけ2フェーズ・コミット部分のロジックが複雑になります。そこで、2フェーズ・コ
ミットの仕組みはTMに任せるのが一般的です。
21
インダウト・ウィンドウ
Application
Application
TransactionManager
TransactionManager
トランザクション開始
(begin)
ResourceManager1
ResourceManager1
Log
RM1の更新
Log
インダウト・
ウィンドウ
コミット/ロールバック
の判断をTMが行う
Log
RM2の更新
トランザクション確定
(commit)
ResourceManager2
ResourceManager2
xa_prepare
xa_ok
Log
準備フェーズ
xa_prepare
Log
xa_ok
Log
ロック保持期間
xa_commit
xa_ok
Log
確定フェーズ
xa_commit
xa_ok
Log
22
Log
インダウト・ウィンドウとは、TMからのxa_prepare要求に対して、RMがxa_okを返してからRMがTMからの
xa_commit要求を受け取るまでの時間になります。これは、RM自身がcommit/rollbackの判断ができない
状態であり、TMからの指示がない限りロックが解除されないことを意味します。詳細は後述します。
22
ログへの書き込み
Application
Application
TransactionManager
TransactionManager
トランザクション開始
(begin)
ResourceManager1
ResourceManager1
Log
RM1の更新
Log
Log
RM2の更新
トランザクション確定
(commit)
ResourceManager2
ResourceManager2
Log FORCE
WRITEが必要
xa_prepare
xa_ok
Log
Log
準備フェーズ
FORCE WRITE
は必要なし
xa_prepare
Log
xa_ok
Log
xa_commit
xa_ok
Log
確定フェーズ
xa_commit
xa_ok
Log
23
Log
FORCE WRITEとは、バッファーでログをキャッシュできず、強制的にログに書き込む必要があるログに
なります。2フェーズ・コミットではFORCE WRITEのログ書込み機能を使用しており、TM/RMは複数の箇
所でログを書き込む為、パフォーマンスがあまり良くないという考慮点がございます。
従いまして、2フェーズ・コミットを利用する際には、パフォーマンス要件を満たしているかを十分にテスト
する必要があります。
23
グローバル・トランザクションにおける最適化
„
確定処理を１フェーズで行うことで性能を最適化する
‹
１フェーズのためトランザクション・ログへの出力はなく、ログ管理も必
要ない
11 Phase
Phase Optimization
Optimization
RMが一つの場合、1PCとなる
commitフェーズのみ
WAS
tx.begin()
DB①
データベースの更新処理
XA対応ドライバー
tx.commit()
READ-ONLY
READ-ONLY
参照処理要求では、prepareフェーズの応答にRMはread-onlyを返す
commitフェーズは実施されない
WAS
tx.begin()
DBのテーブル参照処理
DB①
XA対応ドライバー
DBのテーブルの更新処理
tx.commit()
DB②
24
XA対応ドライバー
TMが管理するトランザクションをグローバルトランザクションとも呼びます。通常、2フェーズ・コミットであ
ればprepare /commitフェーズがあるのですが、グローバルトランザクションにおける最適化はその確定
(commit)フェーズを1フェーズで行います。１フェーズですので、トランザクション・ログへの出力がなく、ロ
グを管理する必要がありません。最適化には、以下の2種類があります。
・ 1 Phase Optimization
TMが起動時にアクセス先のリソースがXA対応であるかを確認し、XA対応でありRMがひとつの場合は、
2フェーズ・コミットではなく1フェーズ・コミットで対応できると判断します。
・READ-ONLY
2フェーズ・コミット処理を行う際に、参照処理要求では、prepareフェーズの応答にRMがread-onlyを返
す事により、commitフェースの実施は必要はないと判断します。
24
(参考)READ-ONLYの処理フロー
RM1：参照処理、RM2：更新処理
Application
Application
TransactionManager
TransactionManager
commit
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
xa_prepare
xa_rdonly
xa_commit
xa_ok
確定フェーズ
RM1：更新処理、RM2：参照処理
Application
Application
TransactionManager
TransactionManager
commit
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
xa_prepare
xa_ok
xa_prepare
xa_rdonly
確定フェーズ
xa_commit
xa_ok
25
グローバルトランザクションにおける最適化のREAD-ONLYの処理フローについてご説明させて頂きま
す。RMがTMからのprepare処理に対して、rd_onlyを返すことにより2フェーズ・コミットではなく1フェーズコ
ミットが実行されるという最適化が行われております。
・RM1：参照処理、RM2：更新処理の場合
ApplicationがTMに対してcommit処理を実行し、TMはRM1に対してprepare処理を実行します。RM1は
xa_rdonlyを返すことにより、TMはRM1に対してcommitフェーズは必要ないと判断し、即座にRM2に対して
のみcommitフェーズを実行します。
・RM1：更新処理、RM2：参照処理の場合
ApplicationがTMに対してcommit処理を実行し、TMはRM1/RM2に対してprepare処理を実行します。こ
の時、RM2は参照処理ですのでxa_rdonlyを返すことにより、TMはRM2に対してはcommitフェーズを実行
せず、RM1のみに対してcommitフェーズを実行します。
25
WAS V6.1が提供するトランザクション機能
‡ WebSphere ASが提供するトランザクション・サービス
‡ WebSphere ASによる独自機能
‡ (参考)拡張JTAのサポート
26
26
WebSphere ASが提供するトランザクション・サービス
„
JTA（Java Transaction API）に準拠したトランザクション・サービス
‹
‹
„
J2EEコンポーネントのアプリケーションの実行環境
トランザクション・マネージャーとしての役割
独自機能
WASの実装機能範囲
J2EE コンポーネント
JDBC, JMS, など
リソース・
マネージャー
(RM)
EJB CMT
JTA
(javax.transaction.xa.XAResource)
JTA
(javax.transaction.UserTransaction)
トランザクション・
マネージャー
(TM)
27
WASはJTAに準拠したトランザクション・サービスを提供しています。J2EEの分散トランザクションモデル
の中で青枠で括られた部分がWASが実装している範囲になり、J2EEコンポーネントであるアプリケーショ
ンの実行環境とTMとしての役割を提供しております。
27
WebSphere ASによる独自機能
„
トランザクションのピア・リカバリー
‹
‹
„
HAマネージャーによるTMのフェイル・オーバー
TM障害時にトランザクションのリカバリーを実施
タイマー機能
‹
トランザクション・タイムアウトの設定可能
¾
„
ある一定時間を経過したトランザクションをロールバックする
モニター機能
‹
‹
実行トランザクションのスナップショット
Tivoli Performance Viewerでトランザクション状態をモニター
¾
¾
実行中のトランザクション数
ロールバックされたトランザクション数 etc…
28
WASが実装している独自の機能としては、以下があります。
＜トランザクションのピア・リカバリー＞
WASV6での新機能になり、HAマネージャーによるTMのフェイル・オーバーと呼ばれています。TM障害
時に、HAマネージャーにより障害を回復するためのサービスが起動し、その起動したサービスがトランザ
クションを最後まで完了させるという機能になります。
＜タイマー機能＞
WASでは、トランザクション・タイムアウトを設定する事が出来ます。ある一定の時間を経過したトランザク
ションに対してロールバックを行うという機能になります。
＜モニター機能＞
実行トランザクションのスナップショットを、管理コンソールやwsadminコマンドを利用して確認することが
出来ます。また、Tivoli Performance Viewerで、実行中のトランザクション数やロールバックされたトランザ
クション数等のトランザクション状態をモニターすることが出来ます。
28
(参考)拡張JTAのサポート
„
JTA に定義されるUserTransactionインターフェースのほかに、
以下のアプリケーション・プログラミング・インターフェースを
提供
‹
ExtendedJTATransaction インターフェース
グローバル・トランザクションID、ローカル・トランザクションID へのアクセス
¾ UserTransactionを使用するアプリ側で、TM(WAS)から割り振られたグ
ローバル・トランザクションID/ ローカル・トランザクションIDを確認できる
‹
SynchronizationCallback インターフェース
トランザクション同期化コールバック
¾ 以下のポイントのいずれかで呼び出される
z
z
アプリケーション・サーバー上で実行される各トランザクションの終わり
コールバックが登録されたトランザクションの終わり
29
JTA に定義されるUserTransactionインターフェースのほかに、 SynchronizationCallbackインターフェー
スとExtendedJTATransactionインターフェースがサポートされました。これを拡張JTAサポートと呼んでおり
ます。詳細につきましては、以下をご参照下さい。
・InfoCenter - 「拡張JTAサポート」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/
info/aes/ae/cjta_extjta.html
・InfoCenter - 「ExtendedJTATransaction」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.javadoc.d
oc/public_html/api/com/ibm/websphere/jtaextensions/ExtendedJTATransaction.html
・InfoCenter - 「SynchronizationCallback」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.javadoc.d
oc/public_html/api/com/ibm/websphere/jtaextensions/SynchronizationCallback.html
29
トランザクション設計ポイント
設計のポイント
30
30
設計のポイント
アプリケーション設計
アプリケーション設計
トランザクション実装方法
トランザクション実装方法
トランザクション・スコープ設計
トランザクション・スコープ設計
障害設計
障害設計
トランザクション・マネージャー障害
トランザクション・マネージャー障害
リソース・マネージャー障害
リソース・マネージャー障害
ヒューリスティック・ディシジョン
ヒューリスティック・ディシジョン
トランザクション・タイムアウト
トランザクション・タイムアウト
運用管理設計
運用管理設計
トランザクション・ログの管理
トランザクション・ログの管理
トランザクション・モニタリング
トランザクション・モニタリング
31
トランザクション設計においては、以下の3つが設計ポイントになります。
＜アプリケーション設計＞
実際にアプリケーションによるトランザクションの実装方法と、どのタイミングでトランザクションを開始/終
了/commit/rollbackするのかについてご説明させて頂きます。
＜障害設計＞
2フェーズコミットの際の障害設計について、以下の観点からご説明させて頂きます。
・トランザクション・マネージャー障害
・リソース・マネージャー障害
また、障害からの回復が難しい場合に、やむ得なく実施されるヒューリスティック・ディシジョンとトランザク
ション・タイマーについてご説明させて頂きます。
＜運用管理設計＞
2フェーズコミットの際に重要となるトランザクション・ログの管理についてとトランザクションのモニタリング
方法についてご説明させて頂きます。
31
トランザクション設計ポイント
アプリケーション設計
‡
‡
‡
‡
‡
‡
‡
‡
‡
トランザクション実装の基本
アプリケーションにおけるトランザクション実装方法
CMT
(参考)CMTの例外処理
BMT(Bean Managed Transaction)
UserTransactionで開始するトランザクション
トランザクション実装方法の選択
トランザクション・スコープ
(参考)トランザクション属性
‡
‡
‡
‡
‡
‡
‡
トランザクション・スコープの考え方①
トランザクション・スコープの考え方②
(参考）トランザクション属性の設定方針
(参考)トランザクション属性の設定
(参考）MDBのトランザクション・スコープ
(参考)トランザクション属性によるトランザクション・スコープ例
リモート・クライアントが開始するトランザクションは要注意
32
32
トランザクション実装の基本
„
トランザクションの開始点、終了点を記述する
‹
JTA （Java transaction API）を用いて実装
try{
ut.begin();
ロジック
トランザクション
ut.commit();
}catch(Exception e){
ut.rollback()
}
tryブロック内で障害が発生した場合
トランザクション内の処理は取消し
33
２フェーズ・コミットを実装する場合の、JTAを用いて実装するサンプルコードになります。
２フェーズ･コミットはut.commit()が発行されてからTMによって行われる処理のため、このtryブロック内で
の障害時には、ut.rollback()によってロールバックが行われます。障害時の挙動については、障害設計で
詳細に説明します。
33
アプリケーションにおけるトランザクション実装方法
„
EJB
‹
CMT(Container Managed Transaction)
‹
BMT(Bean Managed Transaction)
¾
¾
„
トランザクションはEJBコンテナーによって管理される
コーディングによってトランザクションの開始/終了などを制御する
UserTransaction
‹
サーブレット、JSPなど
ユーザー
Servlet
EJB
DataBase
クライアント
EJB
Webコンテナー
Webコンテナー
EJBコンテナー
EJBコンテナー
Application Server
34
アプリケーションにおけるトランザクションの実装方法として、EJBで実装する方法とEJB以外(サーブレッ
ト、JSP等)で実装する方法があります。
＜EJB＞
EJBコンテナーによって管理されるCMT(Container Managed Transaction)と、トランザクション開始/終了
/commit/rollbackなどをコーディングで制御するBMT(Bean Managed Transaction)の2種類があります。
＜EJB以外＞
EJB以外のアプリケーションでは、UserTransactionインターフェースを使用してトランザクション開始/終
了/commit/rollbackなどを制御し、トランザクションを実装します。
34
CMT(Container Managed Transaction)
„
CMT：EJBコンテナーがトランザクションを管理
‹
Beanを呼び出すとEJBコンテナーが自動的にトランザクションの開始/終了を
実施
‹
EnterpriseBeanのデプロイメント・ディスクリプター（DD）で適切なトランザク
ション属性を与えて、トランザクション・スコープを制御
宣言型トランザクション(declarative transaction)
¾
‹
明示的にbegin、commitを記述する必要はない
EJB
EJBClient
トランザクションの開始
Remote method
BusinessLogic
DataBase
トランザクションの終了
トランザクション・スコープ
35
CMTでは、EJBコンテナーがトランザクションを管理します。
EJBClientが、EJBのRemote methodを呼び出すと、EJBコンテナーが自動的にトランザクションの開始/
終了/commit/rollbackを実施します。この時、EnterpriseBeanのデプロイメント・ディスクリプター(DD)で適
切なトランザクション属性を与えて、トランザクション・スコープを制御します。また、EJBコンテナーが管理
するトランザクションの事を、宣言型トランザクション(declarative transaction)と呼びます。
35
(参考)CMTの例外処理 (1/2)
„
システム例外
‹
予測できない、または予測できてもアプリケーションがリカバリーでき
ない障害によって発生した例外
¾
¾
¾
DB接続取得の失敗
JNDI APIの例外
JVMのエラー
⇒ EJBコンテナーが自動的にトランザクションの回復を行う
EJB
EJBClient
トランザクションの開始
Remote method
BusinessLogic
システム例外発生 DB
→トランザクション回復
トランザクションの終了
トランザクション・スコープ
36
システム例外とは、予測できない、または予測できてもアプリケーションがリカバリーできない障害によっ
て発生した例外になります。この場合、EJBコンテナーがトランザクションの回復(ロールバック)を自動的に
実施してくれます。
36
(参考)CMTの例外処理 (2/2)
„
アプリケーション例外
‹
ビジネス･ロジックの中で対応すべき例外
¾
残高不足、メッセージフォーマットの不正など
⇒ アプリケーション例外が発生時、トランザクションをロールバックさせ
たい場合、アプリケーション内で明示的に記述する必要がある
¾
sessionCtx.setRollbackOnly();
EJB
EJBClient
BusinessLogic
トランザクションの開始
Remote method
アプリケーション例外発生
DB
→自動的にロールバックしない
トランザクションの終了
トランザクション・スコープ
37
アプリケーション例外とは、ビジネス･ロジックの中で対応すべき例外(例：残高不足やメッセージフォー
マットの不正)になります。この場合、トランザクションをロールバックさせる為には、アプリケーション内で明
示的にsessionCtx.setRollbackOnly()メソッドを記述する必要があります。アプリケーション例外が発生して
も自動的にロールバックされませんので、ご注意下さい。
37
BMT(Bean Managed Transaction)
„
BMT：SessionBean内のコーディングによってトランザクションの開始/終
了を制御する
‹
‹
‹
javax.transaction.UserTransactionインターフェースを利用
プログラム型トランザクション(programmatic transaction)
EntityBeanはサポートしない
import javax.transaction;
public class StatelessTestBMTBean implements javax.ejb.SessionBean{
private javax.ejb.SessionContext ctx;
public void remoteMethodA(String param1){
UserTransaction ut = ctx.getUserTransaction();
try{
ut.begin();
//Business Logic:
//リソースへの接続など
ut.commit();
}catch(){
ut.rollback();
}catch(SystemException se){
38
(後略)
BMT(SessionBean内のコーディングによってトランザクションの開始/終了を制御する)の場合、
javax.transaction.UserTransactionインターフェースを利用して、ユーザーがコーディングする必要があり
ます。ユーザーがコーディングによって制御するトランザクションを、プログラム型トランザクション
(programmatic transaction)と呼びます。また、BMTはEntityBeanはサポートしておりませんのでご注意下さ
い。
上記にコーディング例がありますが、明示的にut.begin()、ut.commit()と記述され、トランザクションの開
始と終了を実施しております。
38
UserTransactionで開始するトランザクション
„
UserTransactionを使用してトランザクションの開始/終了のコードを記述
‹
‹
‹
サーブレット、JSP
javax.transaction.UserTransactionインターフェースを利用
Webコンテナでは、Contextによるネーミング・サービスを使用して
UserTransactionインスタンスを取得
Context ic = new InitialContext();
UserTransaction ut = (UserTransaction)ic.lookup("java:comp/UserTransaction");
ut.begin()
//ビジネス・ロジック
ut.commit()
トランザクション・スコープ
Servlet
DataBase
Webコンテナ
Webコンテナ
Application Server
39
EJB以外のアプリケーションの場合、BMTと同様ですが、UserTransactionを使用してトランザクションの
開始/終了をユーザーがコーディングする必要があります。EJBと異なる点は、Webコンテナでは、
SessionContextをWebコンテナーでは使用することが出来ませんので、Contextによるネーミング・サービ
スを使用してUserTransactionインスタンスを取得する必要があります。
39
トランザクション実装方法の選択
„
問題発生リスクが低い
迅速な開発が可能
CMT
‹
‹
トランザクション・スコープはBeanメソッドごとに制御
Beanクラスにトランザクションのロジックを書かなくてもよい
¾
¾
¾
„
BMT
‹
‹
„
コーディング時間の短縮
ソース・コードに手を加えることなく、DDにてスコープを変更可能
管理をコンテナーが実施することにより、間違ったトランザクションの使い方がない
Beanがトランザクション・スコープを完全に制御
１リモート・メソッドの中で複数の小さなトランザクションも実行可能
UserTransaction
‹
EJBを使用しない場合
¾
ServletなどWebモジュールからトランザクションを開始
40
CMTとBMT、UserTransactionについて、そのトランザクション実装方法について纏めさせて頂きます。
＜CMT＞
・トランザクション・スコープはBeanメソッドごとに制御
・Beanクラスにトランザクションのロジックを書かなくてもよい
上記よりCMTを使用して開発する方が、問題発生リスクが低く、迅速な開発が可能であると言えます。た
だし、CMTではメソッド毎にトランザクション・スコープが定義されますので、Beanメソッドの中で更に細か
い制御を実施したい場合には、BMTを使用する必要があります。
＜BMT＞
・Beanがトランザクション・スコープを完全に制御可能
・１リモート・メソッドの中で複数の小さなトランザクションも実行可能
＜UserTransaction＞
・EJBを使用しない場合、ServletなどWebモジュールからトランザクションを開始
40
トランザクション・スコープ
„
„
トランザクションの開始から終了までの範囲
トランザクション・スコープの決め方
‹
‹
リソース更新処理が発生する箇所を抽出
リソースの整合性が必要な箇所を特定し、トランザクション・スコープとする
¾
クライアント
処理に失敗したらスコープ内の全処理を戻す
注文
注文情報
保存
在庫確認
在庫確保
受注システム
スコープ①
UPDATE
UPDATE
スコープ②
UPDATE
UPDATE
41
トランザクション・スコープとは、トランザクションの開始から終了までの範囲になります。
スコープを決める際には、まずリソースの更新処理が発生する箇所を洗い出します。
さらに、そのリソースの更新処理に整合性をとる必要がある場合（ACID属性を適用）に、トランザクショ
ン・スコープとします。
41
トランザクション・スコープの考え方①
„
複数の異なる処理をトランザクションでどう分けるか
チケット予約
空席確認
チケット予約
入金処理
空席引き当て
42
複数の異なる処理をトランザクションでどのように分けるかといった場合に、トランザクションスコープを検
討する必要があります。例えば、飛行機のチケットを予約する際に、空席確認→入金処理→空席引き当
てという処理の流れになりますが、どのようにトランザクションを分けるかよって、トランザクションスコープを
選択する必要があります。
42
トランザクション・スコープの考え方①
„
すべて同じスコープとする場合
クライアント
参照
空席確認
更新
入金処理
空席引き当て
„
更新
データの整合性は必須
スコープを分割する場合
クライアント
参照
空席確認
更新
入金処理
空席引き当て
データの整合性は
運用でカバー
更新
43
すべての処理を同一のスコープにする場合、2フェーズ・コミットとする必要があります。その場合には、
処理が一連の流れとなり、必ず空席を割り当てる事が出来ます。この時、データの整合性が保たれます。
パフォーマンスを考慮したりする場合には、2フェーズ・コミットではなく1フェーズ・コミットを採用するケー
スもあるかと思います。その場合には、空席確認/入金処理と空席引き当て処理を別のスコープに定義し
ます。ただし、必ずしも空席を引き当てられるわけではなく、席を余分に用意しておく等、データの整合性
を運用等で補填する必要があります。
43
トランザクション・スコープの考え方②
„
複数の異なる処理をトランザクションでどう分けるか
チケット予約
商品注文
ユーザーからの注文
クレジット請求
CREDIT CARD
1234 5678 9012
VALID FROM
GOOD THRU
XX/XX/XX
XX/XX/XX
PAUL FISCHER
FISCHER
PAUL
時間のかかる処理
商品の出荷
44
前回と同様にチケット予約処理になりますが、今回のケースではクレジット請求処理が含まれており、あ
る程度の時間を要する処理になります。この場合に、どのようにトランザクションを分けて、トランザクション
スコープを選択するかについてご説明させて頂きます。
44
トランザクション・スコープの考え方②
„
非同期処理のトランザクションを採用
商品購入
クライアント
商品注文
クレジット請求
クレジット確認
商品出荷
商品購入
クライアント
商品注文
クレジット請求
クレジット確認
商品出荷
45
クレジット請求のような時間を要する処理の場合、MQなどを使用して、非同期のトランザクションを採用
するという考え方もあります。クレジットの請求処理はキューを介した処理となるため、スコープがわかれま
す。また、クレジットの確認や商品出荷処理は、ひとつのスコープに纏めてトランザクション管理を実装す
ることも、トランザクション管理を実装しないことも可能です。
45
非同期処理におけるトランザクション
„
キューを境にトランザクション・スコープが分かれる
‹
「キューへのメッセージのPUT」、「キューからのメッセージのGET」をト
ランザクション・スコープに含めることができる
クレジット請求
クレジット確認
トランザクション・スコープ
MDB
処理続行
キューを境にトランザクショ
ン・スコープが分かれる
処理に失敗するとロールバックし、キューに
メッセージが戻る。メッセージング機能によっ
て再試行される。
トランザクションとメッセージングの技術を使用することで、リソース
更新処理を確実に実行
46
非同期処理におけるトランザクションではトランザクション・スコープが分かれますが、キューへのメッセー
ジのPUT処理、キューからのメッセージのGET処理をそれぞれのリソース更新処理と同じトランザクション・
スコープに含めることができます。
キューのPUTが完了した段階でクライアントの処理は完了します。クレジット確認処理は、処理が成功す
るまで再試行が行われます。
この場合のアプリケーションは、キューからEJB経由でメッセージを取り出す必要があり、MDB(Message
Driven Bean)を使用することになります。
MDBはEJBの１つで、メッセージ受信をトリガーに非同期に起動することが可能です。
46
（参考）EJBのトランザクション属性
„
EJBの場合、トランザクション属性によってスコープが決定
‹
‹
„
CMTにEJBがどのように参加するかを決定
Beanごとにデプロイメント・ディスクリプター(DD)に指定
トランザクション属性
‹
Required
¾
¾
クライアントがトランザクションを開始していればその中でEJBのメソッドが実行される。
トランザクションを開始していなければEJBコンテナーが開始する
‹
RequiresNew
‹
Supports
¾
¾
¾
新しいトランザクションを開始・終了する
クライアントがトランザクションを開始していればその中でEJBのメソッドが実行される。
トランザクションが開始していなければEJBコンテナーは何もしない
‹
Mandatory
‹
NotSupported
¾
¾
‹
クライアントが必ずトランザクションを開始している必要がある
クライアントがトランザクションを開始しているかどうかに関わらず、EJBのメソッド実行はその
中に含まれない
Never
¾
EJBメソッドは、トランザクションに参加しない
47
EJBの場合には、トランザクション属性によってスコープが決定されます。BMTではコーディングにて設
定する必要があり、CMTではデプロイメント・ディスクリプター(DD)に、以下のトランザクション属性を設定
する必要があります。
・Required
・RequiresNew
・Supports
・Mandatory
・NotSupported
・Never
47
（参考）EJB使用時のトランザクション属性の設定
„
トランザクション内でEJBを実行したい
‹
‹
„
Required
RequiresNew
既存のトランザクション内でEJBを実行したい
‹
Required
Supports
‹
Mandatory
‹
¾
¾
„
トランザクション内で実行されない可能性があるので注意
必ず既存のトランザクション内で実行される
トランザクション外でEJBを実行したい
‹
NotSupported
‹
Never
¾
¾
EJBクライアントで既にトランザクションが開始されている場合は、トランザクションを中断
EJBクライアントで既にトランザクションが開始されている場合は、RemoteExceptionをthrowす
る
48
トランザクション属性の設定方針について纏めさせて頂きます。
＜トランザクション内でEJBを実行したい場合＞
・Required
・RequiresNew
＜既存のトランザクション内でEJBを実行したい場合＞ (クライアントがトランザクションを実行している場
合)
・Required
・Supports (※1)
・Mandatory (※2)
(※1)クライアントがトランザクションを実行していない場合は、Beanのトランザクションが実行されない可能
性があります。
(※2)必ず既存のトランザクション内で実行されます。既存のトランザクションでトランザクション属性を指定
していない場合には、エラーとなります。
＜トランザクション外でEJBを実行したい場合＞
・NotSupported(※3)
・Never(※4)
(※3) EJBクライアントで既にトランザクションが開始されている場合は、トランザクションを中断します。
(※4) EJBクライアントで既にトランザクションが開始されている場合は、RemoteExceptionをthrowします。
48
(参考)トランザクション属性
トランザクション属性
クライアントのトランザクション
（T1）
Beanのトランザクション
（T2）
Required
なし
T2
T1
T1
なし
T2
T1
T2
なし
なし
T1
T1
なし
エラー
T1
T1
NotSupported
なし
なし
T1
なし
Never
なし
なし
T1
エラー
RequiresNew
Supports
Mandatory
49
各トランザクション属性の詳細につきましては、以下をご参照下さい。
・InfoCenter - 「EJB モジュールのコンテナー・トランザクションの定義」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/tejb_addcontainertran.html
(例)RequiresNew – クライアントのトランザクション:T1、Beanのトランザクション:T2
クライアントがトランザクションが開始している場合、Beanのトランザクションは、クライアントのトランザクショ
ンスコープではなく、Beanで定義されたトランザクションスコープになります。
49
（参考）MDBのトランザクション・スコープ
„
„
„
MDBで設定可能なトランザクション属性はRequiredとNotSupportedのみ
スコープの分け方によって、障害時のメッセージの行方やサーバー側の対応が
異なる
onMessage()メソッドのトランザクション属性
‹
Required：コンテナーの受信処理とonMessage()内の処理が同一トランザクション・ス
コープ
¾
¾
¾
１処理が異常終了した場合は全ての処理がロールバックされる
ロールバックした時のメッセージはキューに戻る
EJBコンテナーによる２フェーズ・コミット
UOW
MQからGET
MDB
onMessage(){
データ・ベースへの更新
}
‹
DB
NonSupported：コンテナーの受信処理もonMessage()メソッド内の処理もトランザクショ
ンを管理しない
¾
トランザクション管理が行われない
MQからGET
MDB
onMessage(){
データ・ベースへの更新
}
DB
50
MDBで設定可能なトランザクション属性は、”Required”と”NotSupported”になります。トランザクション・ス
コープの分け方によって、障害時のメッセージの行方やサーバー側の対応が異なります。
【onMessage()メソッドのトランザクション属性】
＜Required：コンテナーの受信処理とonMessage()内の処理が同一トランザクション・スコープ＞
・１処理が異常終了した場合は全ての処理がロールバック
・ロールバックした時のメッセージはキューに戻る
・EJBコンテナーによる２フェーズ・コミット
＜NonSupported：コンテナーの受信処理もonMessage()メソッド内の処理もトランザクションを管理しない＞
・トランザクション管理が行われない
50
(参考)トランザクション属性の設定
„
RADやAST等の開発ツールで、EJBデプロイメント・ディスク
リプターで設定
51
トランザクション属性は、 上記のようにRADやAST等の開発ツールでEJBデプロイメント・ディスクリプター
(DD)にて設定しますので、ご確認下さい。
51
(参考)トランザクション属性によるトランザクション・スコープ例
トランザクション・スコープ
①
EJB client
EJB
EJB
TX属性：Required、
Supports,Mandatory
EJB
TX属性：Required、
RequiresNew
トランザクション・スコープ
EJB client
TX.begin();
TX.commit();
EJB
TX属性：Required、
Supports,Mandatory
TX属性：NotSupported
EJB
TX属性：Required、
Supports,Mandatory
EJB
②
TX属性：NotSupported
トランザクション・スコープ
③
EJB client
TX.begin();
TX.commit();
トランザクション・スコープ
EJB
TX属性：RequiresNew
EJB
TX属性：Required、
Supports,Mandatory
EJB
52
TX属性：NotSupported
上記は、トランザクション属性によりトランザクション・スコープを分けた例になりますので、ご確認下さい。
52
リモート・クライアントが開始するトランザクションは要注意
„
リモート・クライアントからトランザクションを開始する場合、
複数TMによる分散トランザクションになる
クライアント
トランザクション・スコープ
TM1
処理がより複雑に！
Webコンテナ
Webコンテナ
EJBコンテナー
EJBコンテナー
xa_ok
xa_commit
DataBase
Application Server
Application Server
DataBase
従属TM
従属TM
(TM1)
(TM1)
xa_prepare
Log
EJB
ルートTM
ルートTM
ルートRM
ルートRM
Log
TM2
Servlet
従属RM
従属RM
(TM2)
(TM2)
xa_prepare
xa_prepare
xa_ok
xa_ok
xa_commit
xa_ok
Log
Log
xa_ok
Log
xa_commit
xa_ok
Log
53
リモート・クライアントからトランザクションを開始し、複数のアプリケーションでトランザクションスコープを
割り当てた場合、複数TMによる分散トランザクションとなります。上記の処理フローの通り、インダウト・ウィ
ンドウが3箇所になり、書き出されるログ数の増加に伴いログ管理が煩雑になります。
従いまして、リモートクライアントから開始されるトランザクションを実施する場合には、上記考慮点を踏ま
えたうえ、どうしても使用しなければいけない場合のみご利用下さい。
53
トランザクション設計ポイント
障害設計
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
‡
2フェーズ・コミットにおける障害
(参考)2PC障害ケース
(参考)2PC障害発生時の動き
TM障害時のトランザクション・リカバリー処理
インダウト・ウィンドウにおけるTM障害
アプリケーションからのコミット要求前のTM障害
確定フェーズにおけるRM障害
再試行中のトランザクションの表示
RM障害時の再試行の設定
ヒューリスティック・ディシジョン
(参考)ヒューリスティック・ディシジョンの実行
‡
‡
‡
‡
‡
‡
‡
‡
(参考)WAS標準出力への出力
トランザクション障害ポイント
TM障害時のトランザクション・リカバリー方法
TM障害時のトランザクション・リカバリー手法
(参考)ログへの出力
トランザクション・タイマー
トランザクション処理に関係するタイマー
(参考)トランザクション処理に関係するタイマー
54
54
2フェーズ・コミットにおける障害
„
障害によって発生する問題
‹
リソース(DBの行、MQのキュー)にロックがかかる
¾
¾
‹
„
データの不整合
仕掛かり中のトランザクションに対して適切なリカバリーが処
理が必要
‹
„
他のアプリケーションからリソースへのアクセスが不可能
他のアプリケーションまで処理が停止
障害時のトランザクション・リカバリーはTMがコーディネート
障害発生箇所
‹
‹
‹
トランザクション・マネージャー
リソース・マネージャー
ネットワーク
RM
AS
ネットワーク障害
DataBase
RM障害
TM
ネットワーク障害
TM障害
RM
RM障害
55
トランザクションを設計する際の、障害設計のポイントについてご説明させて頂きます。
2フェーズ・コミット障害によって発生する問題として以下があります。
・リソース(DBの行、MQのキュー)にロックがかかり、(他のアプリケーションからリソースへのアクセスが不可
能、他のアプリケーションまで処理が停止)
・データの不整合
従いまして、仕掛かり中のトランザクションに対して、適切なリカバリーが処理が必要になります。障害時
のトランザクション・リカバリー処理は、TMがコーディネートします。また、障害発生箇所は、分散トランザク
ション処理モデルにありましたが、TM/RMになります。TMとRMが別ノードにある場合は、ネットワーク障害
も考えられます。
55
WAS V6.1が提供するトランザクション機能
‡ JTAに準拠したトランザクション・サービスを提供
‡ WebSphere ASによる独自機能
‡ (参考)拡張JTAのサポート
56
56
(参考)2PC障害ケース
アプリケーション
トランザクション
の開始
トランザクション
のコミット
WAS
WASログ
トランザクション
開始
2PC参加RMの
情報
ＭＱログ
MQの更新
確定の準備(xa_prepare)
確定準備への肯定応答(xa_ok)
②
③
PREPARE終了
UR 開始
REDO/UNDO
⑥
PREPARE
開始
終了(FORCE)
⑨
⑦
PREPARE
開始
終了(FORCE)
⑩
確定の準備(xa_prepare)
確定準備への肯定応答(xa_ok)
コミット・フェーズ
④
確定(xa_commit)
⑤
確定への応答(xa_ok)
COMMIT
開始(FORCE)
終了
確定(xa_commit)
⑧
COMMIT終了
DB2ログ
UOW開始
REDO/UNDO
DB2の更新
準備フェーズ
①
DB2
MQ
確定への応答(xa_ok)
COMMIT終了
COMMIT
開始(FORCE)
終了
⑪
57
2フェーズ・コミットの障害は、どこで障害が起こるのかによってそれぞれ発生する問題は変わってきます。
上記に纏めましたので、ご確認下さい。また、次ページ以降にて各発生箇所毎の対応方法についてご説
明させて頂きます。
・UNDOとは
直前にユーザが行った操作を取り消し、元に戻すこと。
・ REDOとは
直前の操作を取り消すUNDO機能を行使して取り消したユーザの操作を、もう一度やり直すこと。
57
(参考)2PC障害発生時の動き (1/2)
„
TM(WAS)に障害が発生したケース
TMの状態
WAS
インフライト：
コミットを表す
PREPARE終了
ログがない
各RMの状態
MQ
インフライト：
PREPARE終了ロ
グがない
障害発生コンポーネントと対応
DB2
WASに障害発生
インフライト：
① MQ、DB2ともにPREPARE終了ログが無いことから、トランザクションはイン
PREPARE終了ロ
フライトと判断され、UNDOログを使ってロールバックされる。WASとの
グがない
RESYNC処理は行われない。
インダウト：
インフライト：
② WASのRESTART時、パートナーログからMQ、DB2がRMであることを認
PREPARE終了ロ PREPARE終了ロ
識。xa_recoverの実行によりMQにインダウトがあることを発見。WASのトラ
グがある
グがない
ンログ内にPREPARE終了ログが無いため、MQへロールバックを指示。
③ WASのRESTART時、パートナーログからMQ、DB2がRMであることを認
インダウト：
インダウト：
PREPARE終了ロ PREPARE終了ロ
識。xa_recoverの実行によりMQ、DB2にインダウトがあることを発見。WAS
グがある
グがある
のトランログにPREPARE終了ログが無いため、MQ,DB２へロールバックを
指示。
④ WASのRESTART時、パートナーログからMQ、DB2がRMであることを認
識。xa_recoverの実行によりMQ、DB2にインダウトがあることを発見。WAS
のトランログ内にPREPARE終了ログがあるためMQ,DB２へコミットを指示。
インコミット：
コミットを表す
PREPARE終了
ログがある
インダウト：
インコミット：
PREPARE終了ロ COMMIT開始ロ
グがある
グがある
⑤ WASのRESTART時、パートナーログからMQ、DB2がRMであることを認
識。xa_recoverの実行によりMQにインダウトがあることを発見。WASのトラ
ンログ内にPREPARE終了ログがあるためMQにコミットを指示。
58
58
(参考)2PC障害発生時の動き (2/2)
„
RM(MQ,DB2)に障害が発生したケース
MQの状態
MQに障害発生
インフライト：
⑥ WASはMQからの応答が無いことを
PREPARE終了ログ
察知してDB2にロールバックを指
がない
示。MQはRESTART時、UNDOログ
を使用してインフライトトランザクショ
ンをロールバック。
DB2の状態
インフライト：
PREPARE終了ロ
グがない
DB2に障害発生
⑨ WASはDB2からの応答が無いこと
を察知してＭＱにロールバックを指
示する。DB2はRESTART時、UNDO
ログを使用してインフライトトランザ
クションをロールバックし、保持して
いたロックを開放する。
⑦ MQはRESTART時、MQログ内の
インダウト：
PREPARE終了ログ
PREPARE終了ログからインダウトが
がある
あることを認識。WASとのRESYNC
が行われる。WASはトランログ内で
のPREPARE終了ログの有無から、
MQへコミット/ロールバックを指示。
インダウト：
PREPARE終了ロ
グがある
⑩ DB2はRESTART時、DB2ログ内の
PREPARE終了ログからインダウト
があることを認識。WASとの
RESYNCが行われる。WASはトラ
ンログ内でのPREPARE終了ログ
の有無から、DB2へコミット/ロール
バックを指示。
インコミット：
⑧ MQはRESTART時、MQログ内の
COMMIT開始ログ
COMMIT開始ログからインコミットが
がある
あることを認識し、コミット処理を終
了させる。
インコミット：
⑪ DB2はRESTART時、DB2ログ内の
COMMIT開始ログ
COMMIT開始ログからインコミット
がある
があることを認識し、コミット処理を
終了させる。
59
59
TM障害時のトランザクション・リカバリー処理
„
„
TM(WAS)で障害が発生した場合、TMの再起動時にトランザクション・ロ
グからトランザクション状態を確認しリカバリー処理を実施する
RM上のトランザクションに対して指示を出す
AS
Transaction
Transaction
Manager
Manager
再起動
AS
Transaction
Transaction
Manager
Manager
TMからRMへの指示
準備フェーズ
・ロールバック
確定フェーズ
・コミット/ロールバック
RM側の動作
in-flight(インフライト)
DataBase
xa_prepareに対して応答を返すまで
・TMが全トランザクションをロールバック
in-doubt(インダウト)
・TMの指示に従う
tranlog
in-commit(インコミット)
・commit処理完了
・TMは何もしない
60
TM(WAS)で障害が発生した場合、TMの再起動時にトランザクション・ログからトランザクション状態を確
認し、リカバリー処理を実施します。TM障害ですので、RM上のトランザクションは仕掛かり中であり、TM
の再起動によってTMがトランザクションの指示を行います。また、その指示内容は、各フェーズによって
異なります。
＜TMからRMへの指示＞
・準備フェーズ
必ずロールバックが行われます。
・確定フェーズ
TMが保持しているトランザクション・ログを参照して、コミット/ロールバックを行います。
＜RM側の動作＞
・in-flight(インフライト)状態（=xa_prepareに対して応答を返すまで)
TMが全トランザクションのロールバックを行います。
・in-doubt(インダウト)
TMの指示に従います。
・in-commit(インコミット)(=commit処理完了)
TMは何もしません。
次ページ以降にて、以下の障害における対応方法について、説明させて頂きます。
・アプリケーションからのコミット要求前のTM障害
・インダウト・ウィンドウにおけるTM障害
・確定フェーズにおけるRM障害
60
アプリケーションからのコミット要求前のTM障害
„
„
トランザクションはTM復旧時に全てロールバック
TM復旧が困難な場合
‹
アプリケーションからコミット要求される前(xa_prepareを受ける前)では、RM側でタイム
アウトが発生することによって、自動的にロールバック
Application
Application
TransactionManager
TransactionManager
ResourceManager1
ResourceManager1
ResourceManager2
ResourceManager2
トランザクション開始(begin)
接続要求
xa_start
接続要求
xa_start
各種処理の実行
トランザクション確定(commit)
xa_end
xa_prepare
61
Log
アプリケーションからのコミット要求前のTM障害については、トランザクションはTM復旧時にすべてロー
ルバックされます。ただし、TM復旧が困難な場合もありますので、アプリケーションからトランザクション確
定(commit)される前(xa_prepareを受ける前)では、RM側でタイムアウトが発生することによって、自動的に
ロールバックがされます。
61
インダウト・ウィンドウにおけるTM障害
„
RMのトランザクションはcommit/rollbackの判断ができない状態
¾
„
データの整合性を保持するには他のRMの実行結果と合わせる必要がある
リソースのロックは保持されたまま
TMの早期復旧のしくみが重要
Application
Application
TransactionManager
TransactionManager
commit
ResourceManager1
ResourceManager1
xa_prepare
xa_ok
準備フェーズ
ResourceManager2
ResourceManager2
Log
xa_prepare
xa_ok
同期点
Log
Log
xa_commit
xa_ok
Log
確定フェーズ
xa_commit
xa_ok
Log
62
TMがRM1に対して、”トランザクション確定の準備(xa_prepare)”を実行するとインダウト・ウィンドウ状態に
なりますが、この時にTMに障害が発生しますと、 RMのトランザクションはcommit/rollbackの判断ができな
い状態となります。また、TMがRM2に対して“トランザクション確定(xa_commit)”を実行した後にTMに障害
が発生しますと、データの整合性を合わせる為にRM1をcommitする必要がありますが、同様に
commit/rollbackの判断ができない状態となってしまいます。更に、TMが障害時は、リソースのロックが保
持されたままになりますので、他のアプリケーションに影響を与えてしまいます。
上記より、これらの状態を回復する為に、TMを早期復旧させる仕組みを確立する事が非常に重要にな
ります。
62
確定フェーズにおけるRM障害
„
TMの動作
‹
準備フェーズで決定したコミット/ロールバックは必ず全RMに指示する必要
がある
‹
TMはRMの復旧まで指示のリトライを行う
¾
完全なデータの整合性を必須とする場合
リカバリーには確実なRMの障害回復のしくみが重要
TransactionManager
TransactionManager
同期点
ResourceManager1
ResourceManager1
Log
xa_commit/xa_rollback
xa_ok
確定フェーズ
ResourceManager2
ResourceManager2
Log
xa_commit /xa_rollback
xa_ok
Log
63
TMはデータの整合性を保つ為、準備フェーズで決定したコミット/ロールバックは必ずすべてのRMに対
して指示する必要があります。確定フェーズにおいてRMに障害が発生した場合、TMはRMの復旧まで指
示のリトライを行います。
従いまして、RMが障害から復旧しないとトランザクションを完了させる事が出来ませんので、確実にRM
を障害回復させる仕組みが重要になります。
63
再試行中のトランザクションの表示
„
サーバー＞アプリケーション・サーバー＞[アプリケーション・サーバー名]
＞コンテナー・サービス＞トランザクション・サービス＞ランタイム
状況
00 -- アクティブ
アクティブ
11 -- ロールバック用にマーク
ロールバック用にマーク
22 -- 準備済み
準備済み
33 -- コミット済み
コミット済み
44 -- ロールバック済み
ロールバック済み
55 -- 不明
不明
66 -- なし
なし
77 -- 準備中
準備中
88 -- コミット中
コミット中
99 -- ロールバック中
ロールバック中
再試行を終了することも可能
[05/11/22 3:16:07:374 JST] 00000032 TransactionIm E WTRN0077W: トランザクショ
ン 00000107B40974760000000200000003ED4983F2A14445910A827609F4D235F8FFB2F2A900000
107B40974760000000200000003ED4983F2A14445910A827609F4D235F8FFB2F2A900000001 はオ
ペレーターによってキャンセルされました。
64
WASがリトライを行っている事を管理コンソールにてモニタリングする事が可能です。管理コンソールより、
サーバー＞アプリケーション・サーバー＞[アプリケーション・サーバー名]＞コンテナー・サービス＞トラン
ザクション・サービス＞ランタイム>再試行トランザクション – 検討をクリックすることで、トランザクションIDと
状況を確認することが出来ます。また、チェックして「終了」ボタンをクリックすることで、再試行(=WASのリト
ライ)を終了させる事も可能です。
64
RM障害時の再試行の設定
„
トランザクション・サービスで再試行回数と間隔を指定可能
‹
サーバー＞アプリケーション・サーバー＞[アプリケーション・サーバー名]＞コンテ
ナー・サービス＞トランザクション・サービス＞ランタイム
再試行回数を指定
再試行回数を指定
デフォルト０では無制限
デフォルト０では無制限
再試行間隔(秒)を指定
再試行間隔(秒)を指定
デフォルト０ではアプリケーション・サーバーが決定
デフォルト０ではアプリケーション・サーバーが決定
1分間隔から開始され、10回ごとに倍になる
1分間隔から開始され、10回ごとに倍になる
65
RM障害時の再試行の設定は、再試行回数と再試行間隔を指定する事が出来ます。管理コンソールより、
サーバー＞アプリケーション・サーバー＞[アプリケーション・サーバー名]＞コンテナー・サービス＞トラン
ザクション・サービス＞ランタイムを選択し、設定して下さい。
65
ヒューリスティック・ディシジョン
„
ヒューリスティック・ディシジョンとは
‹
„
システム運用者が独自に行う確定処理
必要となるのはインダウト・ウィンドウでのTM障害のケース
‹
トランザクション・ログを救えないケース
‹
TM復旧を待たずにインダウト・トランザクション回復を優先したい
¾
¾
„
ディスク装置が破損
リソース(データベースの行・MQのキュー)のロックを早く解除したい
リスク
‹
他のRMの確定結果と一致する保証はなく、データの不整合もあり得る
確定結果は運用者の責任
ヒューリスティック・ディシジョンはデータ不整合の要因となる
66
TM/RM障害が発生した場合、TM/RMを早期回復させる事が重要ですが、それが難しい場合には
ヒューリスティック・ディシジョン（システム運用者が確定処理を独自に行う）を行う必要があります。ヒューリ
スティック・ディシジョンの実行が必要となるのはインダウト・ウィンドウでのTM障害のケースとなり、以下が
挙げられます。
・トランザクション・ログを救えないケース(ディスク装置が破損等)
・TM復旧を待たずにインダウト・トランザクション回復を優先したい(リソース(データベースの行・MQの
キュー)のロックを早く解除したい等)
しかしながら、トランザクションは運用者の判断でもってcommit/rollbackが実行されますので、データの
不整合が発生してしまう可能性がある事をご注意下さい。
・heuristicとは
(学習者の)発見を助ける、自発研究をうながす、発見的な。
66
(参考)ヒューリスティック・ディシジョンの実行 (1/3)
„
DB2 UDB
‹
‹
LIST INDOUBT TRANSACTIONS：インダウト状態のトランザクション一覧を表示
WITH PROMPTING：コミット/ロールバックの確定処理を実施
インダウト・トランザクションのRollback処理
cipher@db2inst1[/home/db2inst1]db2 list indoubt transactions with prompting
1. originator: XA
appl_id: G9BC34E5.F560.050809115428
sequence_no: 0001 status: i
timestamp: 2005-08-09 20:54:28 auth_id: DB2INST1
log_full: n type: RM
xid: 5741534400000024 0000003600000105 A0429D4B00000001 000000014AE7F86B
904150CDEC905A2A 7A64EE286902AC68 00000105A0429D4B 0000000100000001
4AE7F86B904150CD EC905A2A7A64EE28 6902AC6800000001 0000000000000000
000000000002
未確定トランザクション・コマンドか、終了する場合は 'q' を入れてください。
たとえば 'c 1' はトランザクション 1 を手動操作によりコミットします。
c/r/f/l/q: r 1
1. originator: XA
appl_id: G9BC34E5.F560.050809115428
sequence_no: 0001 status: i
timestamp: 2005-08-09 20:54:28 auth_id: DB2INST1
log_full: n type: RM
xid: 5741534400000024 0000003600000105 A0429D4B00000001 000000014AE7F86B
904150CDEC905A2A 7A64EE286902AC68 00000105A0429D4B 0000000100000001
4AE7F86B904150CD EC905A2A7A64EE28 6902AC6800000001 0000000000000000
000000000002
この未確定トランザクションを手動操作により ROLLBACK しますか? (y/n) y
DB20000I ROLLBACK INDOUBT TRANSACTION コマンドが正常に終了しました。
c/r/f/l/q: q
67
DB2 UDBでのインダウト・トランザクションのRollback処理例になりますので、ご確認下さい。
67
(参考)ヒューリスティック・ディシジョンの実行 (2/3)
„
DB2 UDB
インダウト・トランザクションのForget処理
cipher@db2inst1[/home/db2inst1]db2 list indoubt transactions with prompting
1. originator: XA
appl_id: G9BC34E5.F560.050809115428
sequence_no: 0001 status: r
timestamp: 2005-08-09 20:54:28 auth_id: DB2INST1
log_full: n type: RM
xid: 5741534400000024 0000003600000105 A0429D4B00000001 000000014AE7F86B
904150CDEC905A2A 7A64EE286902AC68 00000105A0429D4B 0000000100000001
4AE7F86B904150CD EC905A2A7A64EE28 6902AC6800000001 0000000000000000
000000000002
未確定トランザクション・コマンドか、終了する場合は 'q' を入れてください。
たとえば 'c 1' はトランザクション 1 を手動操作によりコミットします。
c/r/f/l/q: f 1
1. originator: XA
appl_id: G9BC34E5.F560.050809115428
sequence_no: 0001 status: r
timestamp: 2005-08-09 20:54:28 auth_id: DB2INST1
log_full: n type: RM
xid: 5741534400000024 0000003600000105 A0429D4B00000001 000000014AE7F86B
904150CDEC905A2A 7A64EE286902AC68 00000105A0429D4B 0000000100000001
4AE7F86B904150CD EC905A2A7A64EE28 6902AC6800000001 0000000000000000
000000000002
この未確定トランザクションを FORGET しますか? (y/n) y
DB20000I FORGET INDOUBT TRANSACTION コマンドが正常に終了しました。
c/r/f/l/q: q
cipher@db2inst1[/home/db2inst1]db2 list indoubt transactions
SQL1251W 手動操作による照会に戻されるデータはありません。 SQLSTATE=0000
68
DB2 UDBでのインダウト・トランザクションのForget処理例になりますので、ご確認下さい。
68
(参考)ヒューリスティック・ディシジョンの実行 (3/3)
„
WebSphere MQ
‹
dspmqtrn
cipher@mqm[/var/mqm]dspmqtrn
AMQ7056: トランザクション番号は 0,23 です。
XID: formatID 1463898948, gtrid_length 36, bqual_length 54
gtrid [000001059B4F727500000001000000012057F4767A50484000AEA8016E20C7FC90
9EC0CA]
bqual [000001059B4F727500000001000000012057F4767A50484000AEA8016E20C7FC90
9EC0CA000000010000000000000000000000000002]
69
MQでのトランザクション処理の確認例になりますので、ご確認下さい。
69
（参考）WAS標準出力への出力
„
ヒューリスティック・ディシジョン実行後にTMが確定指示を出
すと、WASの標準出力ファイルには以下のエラーが発生
DB2でインダウト・トランザクションに対してRollbackを実施
[05/08/21 22:40:38:314 JST] 00000040 WSRdbXaResour E DSRA0304E: XAException が発
生しました。 XAException の内容と詳細:
The DB2 Error message is : Error executing a XAResource.commit(), Server returned
XA_HEURRB
The DB2 Error code is : -4203
The DB2 SQLState is
: null
。
[05/08/21 22:40:38:324 JST] 00000040 WSRdbXaResour E DSRA0302E: XAException が
発生しました。 エラー・コード: XA_HEURRB (6)。 例外: XA_HEURRB : Error executing
a XAResource.commit(), Server returned XA_HEURRB
[05/08/21 22:40:38:950 JST] 00000040 XATransaction E J2CA0027E: トランザクション
ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54), data(0000010
5d9431b5e000000010000000385761985e1287c6fd7768179ec6f6c953479beb800000105d9431b5e0
00000010000000385761985e1287c6fd7768179ec6f6c953479beb8000000010000000000000000000
000000002)} 内で、dataSource jdbc/SKFitTxDS から XA リソース・アダプターで commit
を呼び出しているときに、例外が発生しました。: com.ibm.db2.jcc.b.se: XA_HEURRB : E
rror executing a XAResource.commit(), Server returned XA_HEURRB
70
ヒューリスティック・ディシジョン実行後にTMが確定指示を出すと、WASの標準出力ファイルには以下の
エラーが発生しますので、ご確認下さい。
70
トランザクション障害設計ポイント
„
TM障害
‹
‹
„
TM障害時のリソースのロック解除のため、TMの早期復旧のしくみが必要
トランザクション・リカバリーにはトランザクション・ログが必要
RM障害
‹
TMはRMの復旧まで、確定指示のリトライを行う
‹
RMの障害回復が重要となる
¾
„
ネットワーク障害
‹
TM障害とRM障害の組み合わせのケース
¾
¾
‹
„
WASの管理コンソールからモニター可能
TMの視点：RM障害に相当
RMの視点：TM障害に相当
ネットワークも早期回復が必要
ヒューリスティック・ディシジョン
‹
‹
トランザクション・ログの損失など、やむを得ない状況以外では避けるべき
データの整合性は保証されない
71
トランザクションの障害設計ポイントを纏めさせて頂きます。
＜TM障害＞
TM障害時のリソースのロック解除のため、TMの早期復旧のしくみが必要になります。
トランザクション・リカバリーにはトランザクション・ログが必要になります。
＜RM障害＞
TMはRMの復旧まで、確定指示のリトライを行います。(この時、WASの管理コンソールから状況をモニ
ターする事が可能です。)
RMの障害回復が重要となります。
＜ネットワーク障害＞
TM障害とRM障害の組み合わせのケースになります。
TMの視点：RM障害に相当します。
RMの視点：TM障害に相当します。
ネットワークも早期回復が必要となります。
＜ヒューリスティック・ディシジョン＞
データの整合性は保証されませんので、トランザクション・ログの損失など、やむ得ない状況以外では使
用する事を避けて下さい。また、データの整合性は保証されません。
71
TM障害時のトランザクション・リカバリー方法
„
TM復旧によるトランザクション・リカバリー方法として、以下の方法が挙
げられます
‹ アプリケーション・サーバー再起動によるリカバリー
‹ 副サーバー・マシンによるリカバリー
‹ HAマネージャーによるピア・リカバリー
72
トポロジー構成を考慮した以下のTM障害時のトランザクション・リカバリー方法について、ご説明させて
頂きます。
・アプリケーション・サーバー再起動
・副サーバー・マシンによるリカバリー
・HAマネージャーによるピア・リカバリー
72
TM障害時のトランザクション・リカバリー手法 (1/3)
„
アプリケーション・サーバー再起動によるリカバリー
‹
‹
BASEでは、手動で再起動
NDでは、ノード・エージェントが自動再起動
¾
¾
¾
デフォルトで自動再始動はON
アプリケーション・サーバーの設定で、監視間隔の設定可能
サーバー＞アプリケーション・サーバー＞[アプリケーション・サーバー名]＞サーバー・インフ
ラストラクチャー＞モニター・ポリシー
73
TM障害時のトランザクション・リカバリー手法として、”アプリケーション・サーバーの再起動によるリカバ
リー”があります。
方法①:アプリケーション・サーバー再起動
BASE構成では、手動でアプリケーション・サーバーを再起動し、トランザクション・ログを読み込んでリカ
バリーする必要があります。ND構成では、ノード・エージェントがアプリケーション・サーバーを自動で再起
動し、トランザクション・ログを読み込んでリカバリーするという仕組みがあります。デフォルトでノード・エー
ジェントによる再起動の仕組みはONになっております。また、上図のように管理コンソールにて設定する
事が可能です。
73
TM障害時のトランザクション・リカバリー手法 (2/3)
„
副サーバー・マシンによるトランザクション・リカバリー
‹
‹
TM復旧に時間がかかる場合は、別マシン上の代替アプリケーション・サー
バーでリカバリーを実施(コールド・スタンバイ)
代替アプリケーション・サーバーは次の項目を一致させなければならない
¾ OS/ホスト名/IPアドレス/構成情報
ノード障害に対応可能だが、リカバリーに時間がかかる
1台のマシンをコールド・スタンバイ
高可用性製品を使用してテイク・オーバー
AS
AS
Transaction
Transaction
Manager
Manager
Transaction
Transaction
Manager
Manager
tranlog
手動で代替アプリケー
ション・サーバーを起動
tranlog
AS
AS
Transaction
Transaction
Manager
Manager
共用ディスク
自動でテイク・オーバー
ログは共用ディスクに配置す
るか手動でコピー
Transaction
Transaction
Manager
Manager
74
TM障害時のトランザクション・リカバリー手法として、”副サーバー・マシンによるリカバリー”があります。
方法②:副サーバー・マシンでのリカバリー
TM復旧に時間がかかる場合は、別マシン上の代替アプリケーション・サーバーでリカバリーを実施しま
す。(コールド・スタンバイ構成)また、代替アプリケーション・サーバーは、OS/ホスト名/IPアドレス/構成情
報(※)を一致させる必要があります。この方法の場合、プロセス障害だけではなくノード障害にも対応する
ことが出来ますが、リカバリーに時間がかかることが注意点になります。
(※)代替アプリケーションサーバーにて新しいトランザクションを受け付ける場合には、ホスト名/IPアドレス
を一致させる必要がありますが、トランザクションのリカバリーだけを目的とする場合はホスト名/IPアドレス
を一致させる必要はありません。
74
TM障害時のトランザクション・リカバリー手法 (3/3)
„
HAマネージャーによるトランザクションのピア・リカバリー
‹
‹
同一クラスター内のTM障害時に、他のクラスター・メンバー上でリカバリー用
のサービスが起動
障害時に実行中だったトランザクションのリカバリーのみを行う
¾
新規トランザクションの実行は行わない
リカバリーに要する時間は数秒だが、共用ディスクが必要
プロセス障害時
正常時
AS1
TM1
AS2
TM2
AS1
TM1 log
TM1
TM1 log
AS2
共用ディスク
TM2 log
TM1
(recover)
TM2
クラスター
共用ディスク
共用ディスク
共用ディスク
TM2 log
75
クラスター
TM障害時のトランザクション・リカバリー手法として、” HAマネージャーによるトランザクションのピア・リ
カバリー”があります。
方法③: HAマネージャーによるトランザクションのピア・リカバリー
同一クラスター内のTM障害時に、他のクラスター・メンバー上でリカバリー用のサービスが起動します。
(AS1とAS2が同一のクラスターとして定義されています。)また、TM1のリカバリープロセス(TM1 recover)は、
新規のトランザクションの実行を行わず、障害時に実行中であったトランザクションのリカバリーのみを行
います。
この方法の場合、リカバリーに要する時間は数秒ですが、共有ディスクが必要になります。
75
(参考)ログへの出力
„
ピア・リカバリーが正常に開始すると、以下のメッセージが出力されます
[05/11/21 17:11:31:179 JST] 0000006d RecoveryDirec I CWRLS0011I: ピア WebSphere サー
バー (garudaCell03¥silver2NodeTX11¥TXMember12) に対してリカバリー処理を実行します。
[05/11/21 17:11:31:219 JST] 0000006d RecoveryDirec I CWRLS0013I: すべてのパーシスタン
ト・サービスが、ピア WebSphere サーバー (garudaCell03¥silver2NodeTX11¥TXMember12) に
対してリカバリー処理の実行を指示されました。
[05/11/21 17:11:31:245 JST] 0000006d RecoveryDirec I CWRLS0013I: すべてのパーシスタン
ト・サービスが、ピア WebSphere サーバー (garudaCell03¥silver2NodeTX11¥TXMember12) に
対してリカバリー処理の実行を指示されました。
[05/11/21 17:11:31:875 JST] 00000073 RecoveryManag A WTRN0027I: トランザクション・サー
ビスは、1 トランザクションをリカバリーしています。
76
ピア・リカバリーが正常に開始すると、上記のようなメッセージが出力されますので、ご確認下さい。
76
構成によるTM復旧方法の選択
„
TMの復旧方法は構成によって以下のように選択されます
クラスター構成である
クラスター構成である
Y
HAマネージャー
による
ピア・リカバリー
N
複数ノード構成である
複数ノード構成である
N
同一ノードのほかのリ
同一ノードのほかのリ
ソースの障害対策に高可
ソースの障害対策に高可
用性製品を使用している
用性製品を使用している
N
Y
アプリケーション・
サーバー再起動
N
共用ディスクが
共用ディスクが
使用可能である
使用可能である
Y
HAマネージャーによる
ピア・リカバリー
Y
高可用性製品を検討
Y
ノード障害時のリカバリー
ノード障害時のリカバリー
を自動化したい
を自動化したい
N
高可用性製品を検討
アプリケーション・サーバー再起動
高可用性製品を検討
※アプリケーション・サーバー再起動を選
択した場合、ノード障害に対応するために
は、副サーバーでの手動回復となる
77
上記にトポロジー構成を考慮したTMの復旧方法を纏めましたので、ご確認下さい。
77
トランザクション・タイマー
„
想定以上に長いトランザクション処理を、Rollbackしたい場合に有効
(Servlet)
ut.begin();
呼び出し
Application Server
(Java Bean) 処理の滞留
処理の滞留
DB更新処理
DB
return result;
ut.commit();
トランザクション・スコープ
トランザクションの長期化が及ぼす影響
システム・リソースへの影響
パフォーマンスへの影響
78
トランザクション・タイマーは、想定以上に長いトランザクション処理をrollbackしたい場合に有効になりま
す。トランザクションが長期化しますと、システムリソースとパフォーマンスに影響を及ぼします。
78
トランザクション処理に関係するタイマー (1/3)
„
合計トランザクション存続時間タイムアウト
‹
機能
¾
¾
‹
１つのトランザクション処理に許容される最大存続時間の設定
タイムアウトの満了時にトランザクションが終了していない場合、トランザクションはロール
バックされる
設定方法
¾
WAS V6.1 管理コンソール
z
¾
¾
‹
IBM RAD V7のEJBディプロイメント記述子
javax.transaction.UserTransactionインターフェースのsetTransactionTimeoutメソッド
標準出力例
¾
‹
サーバー > アプリケーション・サーバー > [アプリケーション・サーバー名] > トランザクション・サービ
ス > 合計トランザクション存続時間タイムアウト
[07/04/03 23:13:24:149 JST] 0000000d TimeoutManage I WTRN0006W: トランザクション
0000010308682B010000000100000003D89F50097754093A8FD456808C9F4F89DB639CB10
000010308682B010000000100000003D89F50097754093A8FD456808C9F4F89DB639CB100
000001 が、30 秒後にタイムアウトになりました。
デフォルト：120秒
79
合計トランザクション存続時間タイムアウトについて、ご説明させて頂きます。
・機能
１つのトランザクション処理に許容される最大存続時間の設定になります。
タイムアウトの満了時にトランザクションが終了していない場合、トランザクションはロールバックされます。
・設定方法
WAS V6.1 管理コンソール
IBM RAD V7のEJBディプロイメント記述子
javax.transaction.UserTransactionインターフェースのsetTransactionTimeoutメソッド
・デフォルト：120秒
79
トランザクション処理に関係するタイマー (2/3)
„
合計トランザクション存続時間タイムアウト
‹
注意事項
¾
トランザクション・タイムアウトの満了時に、即時にロールバックされるわけではない
z
¾
¾
トランザクション・タイムアウトが満了している場合、コンテナに制御が渡った時点で、トラ
ンザクションはロールバックされる
ネットワークのタイムアウト値よりも短く設定する
トランザクション・タイムアウトは満了時に標準出力ログに出力される
(Servlet)
ut.begin();
呼び出し
合計トランザクション
存続時間タイムアウト
Application Server
長時間処理
(Java Bean)
DB更新処理
DB
return result;
Required
ut.commit();
トランザクション・スコープ
80
合計トランザクション存続時間タイムアウトは、以下の注意事項がありますので、ご確認下さい。
・トランザクション・タイムアウトは満了時に標準出力ログに出力されます。
・トランザクション・タイムアウトの満了時に、即時にロールバックされるわけではありません。
・トランザクション・タイムアウトが満了している場合、コンテナに制御が渡った時点で、トランザクションは
ロールバックされます。
・ネットワークのタイムアウト値よりも短く設定する (処理が正常に完了したにも関わらず、ネットワークのタイ
ムアウトがトリガーになってクライアントにエラーが返ってしまいます。)
また、合計トランザクション存続時間タイムアウトは、あくまでもアプリケーションでのut.begin()からut.commit()までの
間のタイムアウトとなりますのでご注意下さい。2フェーズ・コミット処理は、アプリケーションがTMに対してこのcommit
処理行った後の処理になります。
80
トランザクション処理に関係するタイマー (3/3)
クライアント非活動タイムアウト
„
‹
機能
¾
¾
¾
‹
1トランザクションにおける、リモート・クライアントからのリクエスト間の最大許容時間の設
定と監視
タイムアウト満了時にはトランザクションはロールバック
デフォルト：60秒
注意事項
¾
タイムアウトは呼び出される側のサーバーで設定する
Application Server1
Application Server2
(Servlet)
ut.begin();
(EJB)
長時間
処理
DB
EJB呼び出し
DB更新処理
DB
クライアント非活動
タイムアウト
DB参照処理
EJB呼び出し
return result;
ut.commit();
Required
81
トランザクション・スコープ
クライアント非活動タイムアウトについて、ご説明させて頂きます。
・機能
1トランザクションにおける、リモート・クライアントからのリクエスト間の最大許容時間の設定と監視になり
ます。
タイムアウト満了時にはトランザクションはロールバックされます。
デフォルト：60秒です。
・注意事項
タイムアウトは呼び出される側のサーバーで設定して下さい。
81
(参考)トランザクション処理に関係するタイマー (1/2)
„
ハング・スレッドの検出
‹
機能
¾
¾
‹
指定した時間を越えて存続するJ2EE管理スレッドの通知
標準出力へのログ、あるいはJMX Notificationとして通知される
設定方法
¾
¾
デフォルトで検出機能は動作している
管理コンソールよりアプリケーション・サーバーのカスタム・プロパティとして設定
z
z
サーバー > アプリケーション・サーバー > [アプリケーション・サーバー名] > カスタム・
プロパティ
com.ibm.websphere.threadmonitor.interval
9
9
z
com.ibm.websphere.threadmonitor.threshold
9
9
9
z
管理対象スレッドに対して、ハングの是非をチェックする間隔 (秒数)
デフォルト180 秒
スレッドをハングとみなす持続時間 (秒数)
これより長く存続するスレッドは、ハングとして報告される
デフォルト600 秒
com.ibm.websphere.threadmonitor.false.alarm.threshold
9
9
9
9
しきい値が自動的に引き上げられるまでに発生する false アラームの回数
false アラーム T1 回ごとに、しきい値 T2 が 1.5 の因数ずつ引き上げられる
自動調整を使用不可にするには、値をゼロ以下に設定
デフォルト100
82
ハング・スレッドの検出について、ご説明させて頂きます。
・機能
指定した時間を越えて存続するJ2EE管理スレッドの通知になります。(トランザクション処理に特化したタ
イマーではありません。)標準出力へのログ、あるいはJMX Notificationとして通知されます。
・設定方法
デフォルトでこの検出機能は動作しています。管理コンソールより、アプリケーション・サーバーのカスタ
ム・プロパティとして設定して下さい。
com.ibm.websphere.threadmonitor.interval
管理対象スレッドに対して、ハングの是非をチェックする間隔 (秒数)。デフォルト180 秒。
com.ibm.websphere.threadmonitor.threshold
スレッドをハングとみなす持続時間 (秒数) 。これより長く存続するスレッドは、ハングとして報告されます。
デフォルト600 秒。
com.ibm.websphere.threadmonitor.false.alarm.threshold
しきい値が自動的に引き上げられるまでに発生する false アラームの回数になります。false アラーム T1
回ごとに、しきい値 T2 が 1.5 の因数ずつ引き上げられます。自動調整を使用不可にするには、値をゼロ
以下に設定して下さい。デフォルト100。
・JMX (Java Management eXtensions)・・・管理/運用/モニタリングのための標準API
InfoCenter - 「管理プログラムの使用 (JMX)」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/tjmx_programming.html
Java Management Extensions (JMX) Technology
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
82
(参考)トランザクション処理に関係するタイマー (2/2)
„
ハング・スレッドの検出
標準出力のログ・フォーマット
‹
検出時のメッセージ
¾
WSVR0605W: スレッド [THREAD_NAME] が [HANG_TIME]ミリ秒間アクティブで、ハングし
ている可能性があります。 サーバー内には、ハングの可能性のあるスレッドが合計
[TOTAL_THREADS] 本あります。
z
z
z
‹
THREAD_NAME：スレッド名(JVM スレッド・ダンプ内に表示される名前)
HANG_TIME：スレッドがアクティブになってからの概算経過時間
TOTAL_THREADS：ハングとみなされたスレッドの合計数
終了時のメッセージ
¾
WSVR0606W: スレッド [THREAD_NAME] のハングが前に報告されていましたが、完了しま
した。 アクティブ時間が約 [HANG_TIME] ミリ秒になっていました。 サーバー内には、ま
だハングしている可能性のあるスレッドが合計 [TOTAL_THREADS] 本あります。
標準出力例
‹
検出時のメッセージ
¾
‹
[05/04/03 22:36:52:347 JST] 0000000d ThreadMonitor W WSVR0605W: スレッド
"WebContainer : 2" (00000048) が 66726 ミリ秒間アクティブで、ハングしている可能性が
あります。 サーバー内には、ハングの可能性のあるスレッドが合計 1 本あります。
終了時のメッセージ
¾
[05/04/03 22:37:15:771 JST] 00000048 ThreadMonitor W WSVR0606W: スレッド
"WebContainer : 2" (00000048) のハングが前に報告されていましたが、完了しました。 ア
クティブ時間が約 90150 ミリ秒になっていました。 サーバー内には、まだハングしている 83
可能性のあるスレッドが合計 1 本あります。
ハング・スレッドが検出された際の、標準出力のログフォーマットと出力例になります。システムの予防保
守という観点から、ハングスレッドの検出メッセージ(メッセージID：WSVR0605W)を、運用監視ツールの監
視対象とされているお客様事例もございます。あくまでもハングスレッドの検出メッセージが出力されるだ
けで、スレッドを強制的にrollback/commitするわけではないのでご注意下さい。
83
トランザクション設計ポイント
運用管理設計
‡
‡
‡
‡
‡
トランザクション・ログ
トランザクション・ログの配置場所
ログ・スペースがなくなるとトランザクションはロールバック
トランザクション・ログの可読性
TivoliPerformanceViewerによるモニタリング
84
84
トランザクション・ログ
„
„
„
2PC処理で使用される(1PCでは使用しない)
2種類のログをforce write(ファイル・キャッシュなどを使用しない強制的なディスク
書き込み)する
‹ tranlog：2PCトランザクションの明細情報および調停結果を記録
‹ partnerlog：2PCトランザクション処理が実行された環境情報を記録
tranlog,partnerlogそれぞれ、log1、log2の２つのファイルを利用
通常はlog1を使用し、スペースがフルになった場合にlog2を使用する
<WAS_PROFILE_ROOT>/tranlog/<CELL_NAME>/<NODE_NAME>/<SERVER_NAME>/trans
action下に配置
‹
„
トランザクションのリカバリーは、ログからトランザクション状態を確認し実施
トランザクション・ログの配置には信頼性が重要
WAS
TM
TM Log
tranlog
log1
log2
partnerlog
log1
log2
85
運用管理設計において、トランザクション・ログの管理が非常に重要になります。WASでは、次の2種類
のログをforce write(ファイル・キャッシュなどを使用しない強制的なディスク書き込み)します。
tranlog：2PCトランザクションの明細情報および調停結果を記録
partnerlog：2PCトランザクション処理が実行された環境情報を記録
tranlog/partnerlogは、それぞれlog1、log2の２つのファイルを利用し、通常はlog1を使用し、log1のス
ペースがフルになった場合のみlog2を使用します。ログは< WAS_PROFILE_ROOT
>/tranlog/<cell_name>/<node_name>/<server_name>/transaction下に配置されます。トランザクションのリ
カバリー時は、ログからトランザクション状態を確認しますので、トランザクション・ログの配置には信頼性が
重要になります。
85
トランザクション・ログの配置場所
„
トランザクション・ログの可用性
‹
WAS V6.1にはトランザクション・ログを2重化する機能はない
ディスク障害対策として、RAID装置やミラーリングといった、ハードウェアによ
る高可用性の実現が必要
„
ログ書き込みのパフォーマンス
‹
ログへの書き込みにはDisk I/Oが発生するため、ディスクのパフォーマンス
がトランザクションのパフォーマンスに直接影響する
パフォーマンスを考慮する場合は、高速ディスクが必要
86
信頼性を保つ為に、トランザクション・ログの可用性を考慮する必要がありますが、WASV6.1にはトランザ
クション・ログを2重化する機能はありません。ハードウェア等による可用性が必要となります。また、2
フェーズ・コミット処理では複数のログに書き込む必要があり、ログ書き込みの際にはDisk I/Oが発生する
為、パフォーマンスを考慮する場合には高速ディスクが必要となります。
86
ログ・スペースがなくなるとトランザクションはロールバック
„
ログ・スペースがフルになるとトランザクションはロールバック
‹
‹
„
トランザクション・ログのサイジングが必要なケース
‹
‹
„
ログが使用可能になるまで、トランザクションがコミットできない状態
SystemErr.logに、メッセージ「WTRN0083W: トランザクション・ログがフルです。トランザ
クションはロールバックされました。」が出力
同時に相当量のトランザクションが発生
1UOWに時間のかかるトランザクション
ログ・ファイルはサーバー始動時に固定サイズで作成(デフォルト：1024KB)
‹
終了したトランザクションのログ記述が上書きされていく循環ログ
‹
サイズ指定可能：directory_name;file_size
87
ログ・スペースがフルになるとトランザクションはロールバックされますので、同時に相当量のトランザク
ションが発生する場合や1UOWに時間のかかるトランザクションの場合は、トランザクション・ログのサイジ
ングをご検討下さい。トランザクション・ログは、デフォルトでは1MBになり、上書きされる循環ログ(サイズ指
定可能)になります。
87
トランザクション・ログの可読性
„
トランザクション・ログの可読性はない
‹
‹
„
バイナリー・ログである
順次性がない
トランザクション・ログからトランザクション状態を調査することはできない
WAS
Transaction
Transaction
Manager
Manager
ロギング処理
tranlog
トランザクション1に関するログ
トランザクション2に関するログ 処理終了
tranlog
トランザクション2・4
に関するレコードは
GCにより削除
トランザクション1に関するログ
トランザクション5に関するログ
トランザクション3に関するログ
トランザクション3に関するログ
トランザクション4に関するログ 処理終了
トランザクション6に関するログ
トランザクション5に関するログ
トランザクション5に関するログ
新規処理
新規処理
88
トランザクション・ログはバイナリー・ログで順次性がありませんので、トランザクション・ログからトランザク
ション状態を調査することは出来ません。上図では、トランザクション2・4に関するレコードがGCによって削
除され、トランザクションログの順次性がなくなっている事を示しております。
88
Tivoli Performance Viewerによるモニタリング
データ名
説明
GlobalBegunCount
サーバー上で開始されたグローバル・トランザクションの合計数
GlobalInvolvedCount
呼び出し元のグローバル・トランザクションに組み込まれて処理されたトランザクションの合計数
LocalBegunCount
サーバー上で開始されたローカル・トランザクションの合計数
ActiveCount
実行中のグローバル・トランザクションの合計数
LocalActiveCount
実行中のローカル・トランザクションの合計数
OptimizationCount
最適化のために1フェーズコミットに変換されたグローバルトランザクションの合計数
CommittedCount
コミットしたグローバル・トランザクションの合計数
LocalCommittedCount
コミットしたローカル・トランザクションの合計数
RolledbackCount
ロールバックされたグローバル・トランザクションの合計数
LocalRolledbackCount
ロールバックされたローカル・トランザクションの合計数
GlobalTimeoutCount
タイムアウトになったグローバル・トランザクションの合計数
LocalTimeoutCount
タイムアウトになったローカル・トランザクションの合計数
GlobalTranTime
グローバル・トランザクションの平均所要時間(ミリ秒)
LocalTranTime
ローカル・トランザクションの平均所要時間(ミリ秒)
GlobalBeforeCompletionTime
グローバル・トランザクション完了前の平均所要時間(ミリ秒)
LocalBeforeCompletionTime
ローカル・トランザクション完了前の平均所要時間(ミリ秒)
GlobalPrepareTime
グローバル・トランザクション作成の平均所要時間(ミリ秒)
GlobalCommitTime
グローバル・トランザクションのコミットの平均所要時間(ミリ秒)
LocalCommitTime
ローカル・トランザクションのコミットの平均所要時間(ミリ秒)
89
Tivoli Performance Viewerにより、上記の情報をモニタリング出来ますので、ご確認下さい。
・InfoCentrer – 「トランザクションのカウンター」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/rprf_datacounter8.html
89
Hint & Tips:
トランザクションのピア・リカバリー実現のための考慮点
ピア・リカバリーについて
‡ トランザクションのピア・リカバリーが有効な場合
‡ トランザクションのピア・リカバリーを有効に稼働させるための考慮点
90
90
トランザクションのピア・リカバリーが有効な場合
„
アプリケーション・サーバーのプロセス障害やネットワーク障
害が発生した場合です。
‹
トランザクション・ログの破損や消失には対応できません。
¾
トランザクション・ログが破損していた場合
z
z
¾
‹
リカバリー時に、トランザクション・ログを処理できず、リカバリープロセスが失敗します。
プロセスが再起動しても、トランザクション・ログが読み込めないために、プロセスの始
動が行えません。
トランザクション・ログが消失していた場合、リカバリープロセスが、新規にトランザ
クション・ログを作成します。
トランザクション・ログは、耐障害性の高いディスク装置に配置してく
ださい。
トランザクションは、ログが命です！
91
トランザクションのピア・リカバリーが有効な場合は、アプリケーション・サーバーのプロセス障害やネット
ワーク障害が発生した場合になります。トランザクション・ログが破損した場合は、リカバリープロセスが失
敗したりプロセスが起動しないといった状況が発生します。トランザクション・ログが消失した場合は、新規
にトランザクション・ログを作成するという挙動になります。
従いまして、トランザクション・ログは、耐障害性の高いディスク装置に配置して頂くことが必要になります。
91
トランザクションの
ピア・リカバリーを有効に稼働させるための考慮点
„
HAマネージャーによるトランザクション・マネージャーのフェ
イルオーバーを行う際の考慮点
‹
‹
‹
トランザクション・ログを配置するファイル共有システムは何を使用す
るのか？
検知のタイミングは？
フェイルオーバー先を設定する必要があるのか？
②検知のタイミングは？
ClusterMember A
ClusterMember B
HA Manager
HA Manager
トランザクション
マネージャー
トランザクション
マネージャー
ファイル共有
システム
③フェイルオー
バー先を設定した
い
①ファイル共有システム
は何を使うべきなのか？
Tranlog
92
HAマネージャーによるトランザクション・マネージャーのフェイルオーバーを行う際の考慮点として、以下
の3つがあります。次ページ以降にてそれぞれについてご説明させて頂きます。
①トランザクション・ログを配置するファイル共有システムは何を使用するのか？
②検知のタイミングは？
③フェイルオーバー先を設定する必要があるのか？
92
Hint & Tips:
トランザクションのピア・リカバリー実現のための考慮点
ファイル共有システムについて
‡ ファイル共有システムとして何を使用するのか？
‡ (参考)ファイル共有システムの確認方法
93
93
ファイル共有システムとして何を使用するのか？
„
トランザクション・ログを配置できる、ファイル共有システムの
条件は、下記の点です。
‹
‹
„
強制書き込みが可能なこと
排他的ロックが使用可能なこと
下記の製品がサポートされます。
‹
IPネットワークでデータのやりとりを行うファイル共有
¾
¾
‹
SANでデータのやりとりを行うファイル共有
¾
¾
„
Network File System (NFS) version3/version4
Windows Common Internet File System (CIFS)
IBM TotalStorage® SAN File System
(InfoCenterでのサポート明記なし)ジェネラル・パラレル・ファイル・システム(GPFS)
サポート製品が明記されていないが、上記以外のESS/SAN
製品も使用可能です。
‹
クロスマウントが許可されていることが望ましいです。
94
トランザクション・ログを配置できる、ファイル共有システムの条件は、以下の2点になります。
・強制書き込みが可能なこと
・排他的ロックが使用可能なこと
・排他的ロックとは
ロックされたファイルを処理出来るのは1つのリクエストのみになります。リクエストに排他ロックがある場合、
他のリクエストはそのファイルを処理する事が出来ません。
下記の製品がサポートされます。
・IPネットワークでデータのやりとりを行うファイル共有
Network File System (NFS) version3/version4
Windows Common Internet File System (CIFS)
・SANでデータのやりとりを行うファイル共有
IBM TotalStorage® SAN File System
また、明記されていませんが、ジェネラル・パラレル・ファイル・システム(GPFS)も選択肢のひとつになりま
す。
その他、同様にサポート製品が明記されていませんが、上記以外のESS/SAN製品も使用可能です。ま
た、その際にはクロスマウントが許可されていることが望ましいです。次ページ以降にて詳細を説明させて
頂きます。
RedBook - 「WebSphere Application Server Network Deployment V6: High Availability Solutions(SG246688-00)」
http://www.redbooks.ibm.com/abstracts/sg246688.html?Open
94
(参考)ファイル共有システムの確認方法
„
利用するファイルシステムで、障害時にロックが解除されるかを確認する
為のコードが利用できます。
‹
この方法で確認することにより、障害時にトランザクション・ログが解放され、
フェイルオーバー先のトランザクション・マネージャーがファイルを使用できる
かを確認できます。
利用手順
１．下記リンクより取得したプログラムを、[System A]
[System B]に展開します。
2.System Aで障害を
発生させます。
System A
System B
1.TestFileをロックします。
ファイル共有
システム
3.System Bから、
TestFile にアクセス
しようとします。
Test
File
4.ファイルにアクセスできれば、
そのファイルシステムは、
利用可能なファイルシステム
と言えます
２．アクセス対象となるファイル名を、[properties.txt]に記述
します。
※ [properties.txt]内の[filename=]を設定します。
３．System Aから[fsLock.class]を実行し、ファイル共有シ
ステム上のファイルにアクセスします。
※この時点で、ファイルがロックされます。(図[1.])
４．System Aで、プロセス障害やネットワーク障害を
発生させます。(図[2.])
５．System Bから[fsVerify.class]を実行し、確認を行います。
(図[3.])
６．アクセスできたかどうかが表示されます。(図[4.])
Lease based lock test FAILED: Lock not freed
Lease based lock test PASSED: Lock freed
95
利用するファイルシステムで、障害時にロックが解除されるかを確認する為のコードがあります。これによ
り、障害時にトランザクション・ログが解放され、フェイルオーバー先のトランザクション・マネージャーがファ
イルを使用できるかを確認できますので、必要に応じてご利用下さい。
「IBM File System Locking Protocol Test for WebSphere Application Server」
http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg24010222
95
Hint & Tips:
トランザクションのピア・リカバリー実現のための考慮点
ファイル共有システムについて
（NFSを使用した場合の考慮点）
‡ HACMPによるNFSv4サポートについて
‡ (参考)NFSにおける排他的ファイルロックの対応
‡ (参考)トランザクションログに書き込めない場合のTMの挙動
96
96
HACMPによるNFSV4サポートについて
„
„
NFSV4クライアントがNFSサーバーに
「再利用要求(state reclaim operations)」で接続すると、
NFSサーバーのHACMPによるファイルの引継ぎが失敗
HACMPV5.4.1よりNFSV4がフルサポートされ、上記制限が解除
HACMP V5.4.1より完全サポート
ClusterMember A
ClusterMember B
HA Manager
HA Manager
トランザクション
マネージャー
トランザクション
マネージャー
NFS V4
NFS V4
Tranlog
Tranlog
WAS = NFSクライアント
NFSサーバー
97
トランザクション・ログが引き継げない
WAS6.0以降、トランザクション・ログの共有の仕組みとしてInfoCenterにNFSv4サーバーを使用する事が
記載されております。
InfoCenter - 「自動と手動のトランザクション・ピア・リカバリーのいずれかを選択する方法」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/cjta_hacons_log.html
HACMPによるNFSv4サーバーのTakeoverには以前まで制限がありましたが、HACMPV5.4.1よりNFSV4
をフルサポートしているため、この制限は解除となりました。
詳細は、下記テクニカル･フラッシュをご覧ください。
【トランザクション・ログのNFSV4およびHACMPを使用したピア・リカバリー構成について】
http://w3-06.ibm.com/jp/domino02/ise/iseinfo.nsf/TechFlash?OpenView
97
(参考)NFSにおける排他的ファイルロックの対応
„
HA機能は、デフォルトで排他的ファイルロックを使用
‹
NFSV4の場合
¾
‹
NFSV3の場合
¾
lease-based 排他的ロックが提供されている
障害時、NetworkClientがファイルロックをはずす
lease-based 排他的ロックが提供されていない
WASの排他的ファイルロックの機能を使用不可にする設定が必要
「サーバー名」 > 「[コンテナー設定] コンテ
ナー・サービス」 > 「トランザクション・サービ
ス」を選択します
„
ファイルロック機能をOFFにする際の考慮点
‹
‹
サーバが稼動中にも拘らずHAのハートビートの応答が停止する可能性が
ある
複数サーバがTranlogにアクセスした場合、データの保全性が失われる可能
性がある
98
HA機能は、トランザクションデータを保証するために、デフォルトで排他的ファイルロックを使用します。
そのためFileSystemのFileLocking機能を使用しますが、FileSystemにより動作が異なります。
・NFSV4は、lease-based 排他的ロックが提供されているため、障害時にNetworkClientがファイルロックを
はずします。
・NFSV3は、lease-based 排他的ロックが提供されていないため、WASの排他的ファイルロックの機能を使
用不可にする必要があります。
ただし、WASのファイルロック機能をOffにする場合は、以下の点に考慮が必要です。
・システム過負荷またはネットワーク障害などで、サーバが稼動中にも拘らずHAのハートビートの応答が
停止する場合があります。
・WASはファイル･ロックを使用してTranlogへの並行アクセスが発生しないようにしていますが、ファイル
ロックをOffにすることで複数のサーバがTranlogにアクセスする可能性が生じ、データの保全性が失われ
る可能性があります。
ハートビートの待機時間を変更することもできますが、ハートビートによりサーバーの障害を間違って診
断するリスクを減らすことと、自動フェイルオーバーが発生するまでの時間を長くすることはトレードオフに
なります。従いまして、アプリケーションの特性、ネットワーク、およびピーク・ワークロードを考慮して調整
する必要があります。
ファイルロックをOffにする方法は下記をご参照下さい。
InfoCenter - 「ファイル・ロックの使用不可化」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/tj
ta_disable_lock.html
98
(参考)
トランザクションログに書き込めない場合のTMの挙動
„
NFSのマウントオプションにて制御する
‹
ハードマウントの場合
¾
NFSサーバが再度使用可能になるまで再試行する
z
z
z
‹
ハード・マウント時の再試行回数、タイムアウト値の設定可能
NFSマウント・コマンドの -o hard オプションにて定義
NFS クライアントは NFS サーバーが再び使用可能になるまで、失敗した操作を再試
行します。
ソフトマウントの場合
¾
即座にエラーとなる
z
z
NFSマウント・コマンドの -o soft オプションにて定義
ソフト・マウントされたディレクトリーにアクセスしたときにエラーが発生すると、そのエ
ラーはリモート・アクセスを要求したプログラムにすぐに報告される。
99
トランザクション・ログに書き込みできない場合のTMの挙動は、NFSのマウントオプションによって動作が
異なります。ハード・マウントの場合は、NFSサーバが再度使用可能になるまで再試行し、ソフト･マウントの
場合はエラーになります。その際、NFSの設定にてハード・マウント時の再試行回数やタイムアウト値も指
定出来ます。下記をご参照下さい。
InfoCenter – 「トランザクション・プロパティーの、ピア・リカバリー用の構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/tj
ta_cfgpeer.html
InfoCenter - 「ハードまたはソフト NFS マウントがパフォーマンスに対してもつ意味」
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftungd/perf_i
mpl_hard_soft_nfs_mounts.htm
99
Hint & Tips:
トランザクションのピア・リカバリー実現のための考慮点
検知のタイミング
フェイルオーバー先の設定
‡
‡
‡
‡
‡
（参考）HAマネージャによる障害検知
(参考)HeartBeat経路の設定
（参考）ネットワーク障害の検知
(参考)フェイルオーバー先の設定
(参考)HAマネージャーのポリシーを設定する際の注意
100
100
(参考)HAマネージャーによる障害検知
„
HAマネージャーが障害として検知するケース
‹
１．プロセスダウンにより、ソケットがクローズされた場合
¾
‹
２．HAマネージャー間のHeartBeatが断絶した場合
¾
‹
プロセスに障害が発生したことにより、ソケットがクローズされるとHAマネジャー
により即時検知され、対象ノードがダウンしたと判断します。
ネットワーク障害やサーバーのハングにより、HeartBeatの送信が正常に行えな
い回数が一定回数を超えると、HAマネージャーは対象ノードがダウンしたと判断
します。
３．OSのTCP/IP KeepAliveのタイムアウトにより、ソケットがクローズ
された場合
¾
OS側のTCPKeepAlive時間が経過した場合、コネクションがクローズされます。こ
のコネクションのクローズを検知し、対象サーバーがダウンしたと判断します。
ClusterMember A
ClusterMember B
HA Manager
HB
HA Manager
HB
トランザクション
マネージャー
トランザクション
マネージャー
101
HAマネージャーが障害として検知するケースは以下の3ケースです。
１．プロセスダウンにより、ソケットがクローズされた場合
２．HAマネージャー間のHeartBeatが断絶した場合
３．OSのTCP/IP KeepAliveのタイムアウトにより、ソケットがクローズされた場合
101
(参考)ネットワーク障害の検知
„
ネットワーク障害は、HAマネージャーのHeartBeatにより検知されます。
これを調整することで、障害検知までの時間を設定できます。
‹
IBM_CS_FD_CONSECUTIVE_MISSED
¾
‹
IBM_CS_FD_PERIOD_SECS
¾
‹
ハートビートの失敗数です。(デフォルト：6回)
ハートビートの送信間隔です。(デフォルト：30秒)
設定は、コア・グループのカスタム・プロパティに行います。
「コア・グループ」＞「コア・グループ設定」
＞「DefaultCoreGroup」を選択
「新規作成」を選択し、
値を設定します。
「カスタム・プロパティ」を選択
102
ネットワーク障害はHeartBeatにより検知され、この値を調整することで、障害検知までの時間を設定出
来ます。設定は、管理コンソールのコア・グループのカスタム・プロパティにて行います。
・IBM_CS_FD_CONSECUTIVE_MISSED
ハートビートの失敗数です。(デフォルト：6回)
(WASV6の時はデフォルト20回になり、V6.1にて変更されましたのでご注意下さい。)
・IBM_CS_FD_PERIOD_SECS
ハートビートの送信間隔です。(デフォルト：30秒)
(WASV6の時はデフォルト10秒になり、V6.1にて変更されましたのでご注意下さい。)
InfoCenter - 「コア・グループ障害検出プロトコル」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/inf
o/ae/ae/crun_ha_faildetect.html
102
(参考)HeartBeat経路の設定
„
HeartBeatとして、デフォルトのトランスポート・タイプである
「DCS」を選択している場合のHeartBeat経路は、
DCS_UNICAST_ADDRESSを使用して指定します。
‹
クラスター・メンバー毎に設定が必要です。
「サーバー名」＞「ポート」＞
「DCS_UNICAST_ADDRESS」
を選択します
「ホスト」を、HeartBeat経路の
IPアドレスまたは、
ホスト名に変更します。
103
HeartBeat経路は、管理コンソールより設定可能ですので、ご確認下さい。
103
(参考)フェイルオーバー先の設定
„
フェイルオーバー先を設定する場合は、ポリシーを作成して
定義を行う必要があります。
‹
クラスターメンバーが多数あり、フェイルオーバー先をグルーピングし
たい。
¾
全クラスター・メンバーに対するポリシーを作成します。
z
ポリシー
z
一致基準
9
9
9
z
z
TYPE=WAS_TRANSACTIONS
GN_PS=[セル名]/[ノード名]/[クラスター・メンバー名]
「優先サーバーのみ」をチェック
優先サーバー
9
‹
「Nポリシー中の1つ」
グルーピング対象のクラスターメンバーを選択します。
処理能力の高いサーバーで、フェイルオーバー処理をさせたい。
¾
クラスター単位のポリシーを作成します。
z
ポリシー
z
一致基準
9
9
9
z
「Nポリシー中の1つ」
TYPE=WAS_TRANSACTIONS
IBM_hc=[クラスター名]
優先サーバー
9
処理能力の高いノード上で稼働するクラスターメンバーを選択します。
104
フェイルオーバー先を設定する場合は、ポリシーを作成して定義を行う必要があります。フェイルオー
バー先をグルーピングしたり、処理能力の高いサーバーでフェイルオーバー処理を実施する事が出来ま
すので、ご確認下さい。
104
(参考)HAマネージャーのポリシーを設定する際の注意
„
トランザクション・マネージャーに対するポリシー設定を行う
場合は、注意が必要です。
‹
トランザクション・マネージャーを起動できない場合、アプリケーショ
ン・サーバーの起動が出来ません。
¾
¾
トランザクション・マネージャーのポリシーで、「Nポリシー中の1つ」を設定するとき
には、必ず「フェイルバック」を行い、トランザクション・マネージャーが自身のプロ
セスで、稼働するようにしてください。
「オペレーション・ポリシーなし」は使用できません。
105
トランザクション・マネージャーに対するポリシー設定を行う場合は注意が必要ですので、上記をご確認
下さい。
105
このセッションで学習したこと
„
トランザクションの基礎
‹
„
WAS V6.1が提供するトランザクション機能概要
‹
„
トランザクションのピア・リカバリー、タイマー機能、モニター機能につ
いて確認しました。
トランザクション設計ポイント
‹
‹
‹
„
トランザクション、ローカル・トランザクション、分散トランザクションとは
何かについて確認しました。
アプリケーションにおけるトランザクション実装方法・スコープについ
て確認しました。
2PCにおける障害とリカバリー方法について確認しました。
トランザクション・ログについて確認しました。
Hint & Tips:
トランザクションのピア・リカバリー実現のための考慮点
‹
ピア･リカバリー構成の考慮点について確認しました。
106
106
参考資料
„
WebSphere AS V6.1 Information Center
¾
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
„
Redbook「WebSphere AS V6:High Availability Solutions」
„
IBM WebSphere Developer Technical Journal
¾
‹
Transactional high availability and deployment consideration in
WebSphere Application Server V6
¾
‹
http://www128.ibm.com/developerworks/websphere/techjournal/0504_beaven/0504_beaven.html
Automate peer recovery for transactions and messages in Websphere
Application Server V6.0.x
¾
„
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246688.html?Open
http://www-128.ibm.com/developerworks/websphere/techjournal/0509_lee/0509_lee.html
pSeries and AIX Information Center
¾
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp
107
107