明日から4連休です．(^^; 16日(金)と19日(月)，いずれも19時から予定があるからなのですが，そのために仕事を休むとはやる気満々というのかやる気nullというのか(苦笑)． 16日(金) OO Enkai 明日の夜は，かつてニフティサーブのプログラマーズフォーラム(プロ)「OOについて議論する」会議室でいろいろと勉強させていただいた常連の方々と宴会です．それがOO Enkai(笑)．当時はOO OFFと呼ばれていたものが，パワーアップして復活しました．どうパワーアップしたかは謎です． ニフティのフォーラムや会議室が寂れてしまい，自分も休会して久しいこともあって，数年ぶりにお会いする人が何人も．とても楽しみです． ちなみに，私がはてなをはじめたのは，その常連だったはぶさんやまこたんを見かけた影響です．いろいろ刺激をもらって感謝してます． 19日(月) 第11回日本XPユーザー会 Ma

さて，JBossTXの続きをやろう． 先週までの調べでTransactionImplにXAResourceを登録していたのはTxConnectionManagerであることが判明している． TxManagerのgetTransaction()メソッド実装は以下． public Transaction getTransaction() throws SystemException { ThreadInfo ti = getThreadInfo(); TransactionImpl current = ti.tx; if (current != null && current.isDone()) { current = null; disassociateThread(ti); } return current; }getThreadInfo()はjava.lang.ThreadLocalから

まだJCA方面についてはほとんど調査ができていないので確定ではないが，"org.jboss.resource.connectionmanager.TxConnectionManager"クラスがTransactionImplにXAResourceを追加していると思われる． TransactionImplにXAResourceを追加するためには，そのためにはTransactionImplのenlistResourceメソッドを呼ぶ必要がある．このメソッドを呼んでいるのがこのTxConnectionManagerだ． JBoss4 Application Server Guildの第7章（http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch7.chapt.html）でJCAにおけるサーバとの連携の3つのタスクの1つ"Transaction M

先ほどのコード実行で何も起きなかった理由は簡単．"Recoverable Resource"が存在していなかったからだ． TransactionContextはTransctionManager内で自動的に生成される．言い換えると，TxManager内でTransactionImplインスタンスは自動的に生成される． しかし"Recoverable Resource"であるXAResourceインタフェース実装インスタンスはそうではない． TxManagerもTransactionImplに結構処理を委譲している．beginは自分で処理をしているが，XAResourceに対するcommit/rollbackはTransactionImplに委譲して行っている． TxManagerがやっているのはTransactionContextを通じた状態管理とTransactionContextそのも

"org.jboss.tm.TxManager"クラスはJBossにおける"javax.transaction.TransactionManager"の実装クラスです． 「TX その１　JTAによる分散トランザクションの構成要素の定義」で一度触れたように，TransactionManagerというのはJTAの中で中心的な役割をにないます． JBossではJNDI名"java:/TransactionManager"でバインドされているTransactionManager実装クラスが使われる仕組みになっていますので，ここを書き換えておけばTxManager以外のTransactionManager実装をJBossに使わせることも可能です． TxManagerはデフォルトでは，オブジェクト名"jboss:service=TransactionManager"，実装クラス"org.jboss.t

TxManagerに行く前にもう1点だけ確認すべき点が． TxInterceptorCMTクラスで"Required"などのトランザクション有りの設定で対象のEJBが新しいトランザクションを開始した場合によばれるendTransactionメソッドの一部 try { // Marked rollback if (tx.getStatus() == Status.STATUS_MARKED_ROLLBACK) { tx.rollback(); } else { // Commit tx // This will happen if // a) everything goes well // b) app. exception was thrown tx.commit(); } }setRollbackOnlyが呼ばれてトランザクションコンテキストのstatusが"STATUS_MARKED_

昨日の日記 あとはCMTが"java:/TransactionManager"をlookupして使っているということが証明できれば，CMT／BMTといったレイヤーの話を切り捨ててTransactionManager以下のレイヤーのみで話を進められる． これを調べるためにCMT関連のソースを読んでいたのだが「かなり」道草を食ってしまった．そろそろ本題に戻ろう． TxInterceptorCMTクラスにある"javax.transaction.TransactionManager"型インスタンス変数は親クラスであるAbstractTxInterceptorクラスから継承したもの．AbstractTxInterceptorクラスのcreateメソッドを見ると public void create() throws Exception { super.create(); tm = getConta

蛇足． CMTを使う場合に"ejb-jar.xml"で指定するトランザクションタイプとして"NotSupported", "Required"等々のキーワードがあると思う． これらのキーワードは，EJBへの毎回の呼び出し時にインターセプトの1つとして呼び出されるTxInterceptorCMTクラスのrunWithTransactionsメソッドで処理される．switch-case構文と定数を使って場合わけされて処理される． 例えばトランザクションタイプが"NotSupported"の場合，runWithTransactionsメソッドの中では， 呼び出し元から引き継いだトランザクションコンテキストを一度退避させて トランザクションコンテキストを空にして 次のインタセプタを呼び出す． インタセプタからインタセプタへの呼び出し連続的に行われて StatelessSessionInstance

standardjboss.xmlというファイルは先頭付近を見るに， <!-- ===================================================================== --> <!-- Standard JBoss EJB Configurations --> <!-- ===================================================================== --> ということらしいです． 後から調べたらここ(http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch01.html)に書いてありますね．勉強不足．orz さてstandardjboss.xmlをざっと眺めるとStateless Session Beanのところとかには <!--

CMTかBMTかといった設定はejb-jar.xmlに記述されるもの．J2EEサーバ側ではデプロイ時にこのXMLファイルに書かれた内容をパースしてEJBコンテナの振る舞いをどのようにするかを決定するという流れになる． JBossではEJB1つにつきEJBContainerも1つそれに対応させて生成するアーキテクチャを採用している．つまりCMTであればejb-jar.xmlに" Container"と書くわけだが，この情報がいろいろ経由してEJBContainerの生成時の引数として渡されることになる． ではその各EJBにあわせたEJBContainerを生成しているのはどのクラスか？というとちょっとまだ自信がないのだが，どうやら"org.jboss.ejb.EjbModule"クラスであるようだ．このクラスにcreateStatelessSessionContainerメソッド他，各タイプ

"java:/TransactionManager"のJNDI名でbindしたのはTransactionManagerServiceクラス（MBean）．クラスコメントにご丁寧に説明書きが． This is a JMX service which manages the TransactionManager. The service creates it and binds a Reference to it into JNDI. createServiceメソッドを見る． XidFactoryMBean xidFactoryObj = (XidFactoryMBean) getServer().getAttribute(xidFactory, "Instance"); TransactionImpl.xidFactory = xidFactoryObj; TransactionImpl.

このクラスはBMTなEJBでUserTransactionを使用する際に使われる，UserTransactionの実装クラス．本命はTransactionManager実装の解析だけど，CMTとBMTとTransactionManagerの境界線がまだ自分的には見えていないのでもう少しこの辺りを勉強． いきなりだが，ServerJVClientUserTransactionクラスで使われるTransactionManagerはJNDIから"java:/TransactionManager"で取得してきた"javax.transaction.TransactionManager"インタフェースの実装クラス．ここもインタフェースによって分離が図られている．begin, commit, rollback他どれをとっても単純に委譲しているだけ． 御しまい．

4.2. JBoss Transaction Internalsについてのメモ JBossではTransactionManager以下，全ての要素をJTAのインタフェースを通して利用している．よっぽど特殊な要望がなければやらないだろうが，JBossTXの代わりに別のJTA実装を突っ込むことも実際可能．JNDI名"java:/TransactionManager"で登録すればあとはインタフェースを通じて動くはず． ふと思ったんだけど，インタフェースをばしばし切ることでプロダクトとしての柔軟性，移植性は格段にあがる．でもソースを読んで内部設計をリバースエンジニアリングする立場からするとインタフェースが1枚増えるごとに難しくなっていくような・・・．JMXとJNDIが犯人．蛇足ですが． ソースからのリバースエンジニアリング UserTransactionをJNDIに登録しているのは"jboss:s

4.1.4. Heuristic exceptionsについてのメモ JTAにおける分散トランザクション上での例外の規定．分散トランザクション環境ではTransactionManagerを中心に複数のプロセス（Recoverable Resource）が稼動している．これらのプロセスは別筐体にあったりして，その場合にはネットワークをまたいで互いに繋がっていることになる． ということになると，クラスタリングの分野ではおなじみの，各プロセスは正常に稼動しているけれどもネットワークに障害が発生した場合（一時的に通信がストップするなど），TransactionManagerが全てのRecoverable Resouceを管理しきれなくなるという事態が当然発生する． このような場合に備えて，TransactionManagerはcommitやrollback指示を出した後にそれらが全てのRecove

JBoss4 Application Server Guide: 4.1.2. The components of a distributed transaction より Transaction Manager：javax.transaction.TransactionManagerインタフェースを実装，分散トランザクション全体を管理する． Transaction Context：javax.transaction.Transactionインタフェースを実装，トランザクションのコンテキストそのもの． Transaction Client：トランザクションの開始とか終了とかする人，UserTransactionを使っているクラスとか? Transaction Object：EJBは基本的にこれに該当する．１つのクラスがTransaction ClientとTransaction Objec