9.2.5. Concurrency Controller
Concurrency Controller は
LockManager
クラスにより実装され、適切なデフォルトの動作を提供します。このデフォルトの動作は、プログラム済みクラスの特定セマンティクスを使い必要であればプログラマが上書きすることができます。StateManager
クラスと永続性については、インターフェース経由で同時実行制御の実装へアクセスします。インターフェースに対して提供している同時実行制御に関する実装は今のところ、以下のようになっています。
- リモートサービスへのアクセス
- ローカルディスクおよびデータベース実装の両方 (これらでロックをローカルのファイルシステムかデータベースに書き込み永続化します)。
- 純粋なローカル実装 (この実装にてロックを作成した仮想マシンのメモリ内にてロックが保持されます)。この実装は、ローカルディスクへロックを書き込むよりもパフォーマンスが優れていますが、オブジェクトを仮想化マシン間で共有することができません。重要なのは、SecurityManagerの影響を受ける可能性のある要件を持たない、基本的なJava オブジェクトとなっています。
Concurrency Controller に対するプライマリAPIは、
setlock
操作を介します。デフォルトでは、ランタイムシステムはオブジェクト毎のmultiple-reader/single writer ポリシーに従い厳密な2相ロッキングを強制します。しかし、図9.1「JBoss Transaction Service のクラス階層」で示されているように、Lock
クラスから継承することでプログラマは、自身のロック実装に別のロック矛盾ルールを提供しtype specific concurrency control (タイプ固有の同時実行制御)を有効にします。
ロックの取得はプログラマの管理のもと行う必要があります。
StateManager
が操作によりオブジェクトが変更されるかを判断できないため、LockManager
が操作に読み込みあるいは書き込みロックが必要かを決定できないのです。しかし、ロック解除はシステムが制御しておりプログラマが介入する必要はありません。こうすることで、2相プロパティは正しく保持されるようにします。
public abstract class LockManager extends StateManager { public LockResult setlock (Lock toSet, int retry, int timeout); };
LockManager
クラスは、適時オブジェクトへのロック設定、解除に関するリクエストを管理します。StateManager
から取得しているあtめ、継承された機能の一部が呼び出された時は制御も可能です。例えば、LockManager
は、書き込みロックの設定がされると呼び出している操作はオブジェクトを変更することになることが分かり、オブジェクトが回復可能であればリカバリ情報の保存がトリガーされる可能性があることが分かります。同じように、ロックの取得に成功すると、activate が呼び出されます。
例9.3 書き込みロック取得の試行
public class Example extends LockManager { public boolean foobar () { AtomicAction A = new AtomicAction; boolean result = false; A.begin(); if (setlock(new Lock(LockMode.WRITE), 0) == Lock.GRANTED) { /* * Do some work, and TXOJ will * guarantee ACID properties. */ // automatically aborts if fails if (A.commit() == AtomicAction.COMMITTED) { result = true; } } else A.rollback(); return result; } }