EJBはトランザクションのやり方次第で速くなるのに…：WebSphereサーバ・チューニング入門（6）（2/4 ページ）

[上野憲一郎，日本アイ・ビー・エム]

「Access Type」を加えて「アクセス・インテント」ポリシーを決定！！

　前述した、「Concurrency Control (Locking Strategy)」と「トランザクション分離レベル」に加え、アクセス・タイプとして、「Read処理」か「Update処理」かを加味して、7種類「アクセス・インテント」ポリシーの中から１つを決定します。「アクセス・インテント」ポリシーの設定を以下にまとめます。

ポリシー （プロファイル名）	Concurrency Control	アクセス・タイプ	トランザクション分離レベル
wsOptimisticRead	optimistic	read	Read Committed
wsOptimisticUpdate	optimistic	update	Read Committed
wsPessimisticUpdate -NoCollision	pessimistic	update	Read Committed
wsPessimisticRead	pessimistic	read	Repeatable Read
（Oracle：Read Committed） wsPessimisticUpdate	pessimistic	update	Repeatable Read
（Oracle：Read Committed） wsPessimisticUpdate-WeakestLockAtLoad （省略時ポリシー）	pessimistic	update	Repeatable Read
（Oracle：Read Committed） wsPessimisticUpdate-Exclusive	pessimistic	update	Serializable
表3　「アクセス・インテント」ポリシー

1. wsPessimisticUpdate
   これを指定した場合、「SELECT …… FOR UPDATE」文が使用され、DBの行の更新ロックが獲得される
2. wsPessimisticUpdate-WeakestLockAtLoad
   省略時の値として使われる。データをロードする際に、EJBコンテナは、ターゲットのDBの「weakest lock」を使用する。つまり、行は共有ロックされる。更新が必要になった場合に、更新ロックが獲得される
3. wsPessimisticUpdate-NoCollision
   「Read Committed」が使用され、行のロックは獲得ない（「SELECT …… FOR UPDATE」を使用しません）。従って、同じ行に対して、同時更新がされないことを確信できない場合には使用を避けるようにする
4. wsPessimisticUpdate-Exclusive
   DB分離レベルの「Serializable」が使用され、データのロード時に「SELECT …… FOR UPDATE」が使用される
5. wsPessimisticRead
   Entity Beanが読み込み専用である場合に使用する。「Repeatable Read」が使用される
6. wsOptimisticUpdate
   「Optimistic Locking Strategy」を使用したEntity Beanの更新に使用する
7. wsOptimisticRead
   「Optimistic Locking Strategy」を使用したEntity Beanの読み込み専用に使用する。wsPessimisticReadが「Repeatable Read」を使用するのに対して、wsOptimisticReadは「Read Committed」を使用する

「アクセス・インテント」ポリシーの設定の仕方

　WASでの「アクセス・インテント」ポリシーの設定は、AST（あるいは、RAD）を使用します。［EJBデプロイメント記述子］→［アクセス］タブ→［WebSphere拡張機能］→［Entities 2.x のデフォルトのアクセス・インテント（Bean レベル）］で、各Entity Beanに対して設定します。

　図6は、「wsOptimisticRead」を指定した例です。

図6　「アクセス・インテント」ポリシーの指定例「wsOptimisticRead」の場合（画像をクリックすると拡大します）

　図7は、「wsPessimisticUpdate-WeakestLockAtLoad」（デフォルト値）を指定した例です。

図7　「アクセス・インテント」の指定例「wsPessimisticUpdate-WeakestLockAtLoad」の場合（画像をクリックすると拡大します）

【2】Lifetime in Cache（データ・キャッシュ）

　WASでは、トランザクションをまたがるデータのキャッシュを設定できます。これは、「Lifetime in Cache」あるいは、「データ・キャッシュ」と呼ばれるオプションです。

　指定したキャッシュ生存時間が経過するまで、データはキャッシュに保持されます。データがキャッシュに保持されている間は、そのデータに対するリクエストに対して、DBへの問い合わせは行われません。データ・キャッシュの「Invalidation Timer」（無効果までの時間）を指定することにより、キャッシュ内でのデータの保持時間を設定します。

「Lifetime in Cache」の設定の仕方

　AST（あるいは、RAD）を用い、「キャッシュ使用での存続時間」および「キャッシュ内での存続時間」を指定します。「キャッシュ使用での存続時間」には、「OFF」「ELAPSED_TIME」「CLOCK_TIME」「WEEK_TIME」のいずれかを指定します。

図8　「Lifetime in Cache」の設定

• 「OFF」を指定
  トランザクション終了時にキャッシュされたデータは無効になる
• 「ELAPSED_TIME」を指定
  トランザクション終了後、「キャッシュ内での存続時間」で指定した値の時間が経過するまでの間（図8の例では、トランザクション終了後、6分間）、キャッシュされたデータは有効
• 「CLOCK_TIME」を指定
  トランザクション終了後、「キャッシュ内での存続時間」で指定した時間まで、キャッシュされたデータは有効
• 「WEEK_TIME」を指定
  曜日と時間をキャッシュ有効期間として指定できる

【3】Entity Beanキャッシュ（コミット・オプション）

　WASでは、EJBの「コミット・オプション」の設定をすることにより、Entity Beanキャッシュを利用可能です。Entity Beanに対応するデータをDBからいつロードし、どのようにキャッシュするかを設定でき、コミット・オプション A、B、Cに対応しています。

• Option Aキャッシング
  トランザクション・スコープ外のデータをキャッシュすることによりハイ・パフォーマンスを提供。DBへの排他的アクセスの場合に使用
• Option Bキャッシング
  Entity Beanはトランザクションをまたがってキャッシュされるが、各メソッドが開始する際にリロードされる
• Option Cキャッシング（省略時設定）
  Entity Beanは各トランザクションが開始される際にDBからリロードされる。パフォーマンス性能面からは一番不利といえる

「コミット・オプション」の設定の仕方

　コミット・オプションの設定は、AST（あるいは、RAD）を使用します（図9）。　

図9　Option Cの設定例

　［Beanのキャッシュ］の設定で、［アクティブ化］と［ロード］の組み合わせで決定されます（表4）。

コミット・オプション	アクティブ化	ロード
Option A	ONCE	ACTIVATION
Option B	ONCE	TRANSACTION
Option C	TRANSACTION	TRANSACTION
表4　コミット・オプションの指定

　［アクティブ化］の「ONCE」は、Beanが最初にアクセスされた際にアクティブになります。「TRANSACTION」は、トランザクション開始時にアクティブになります（省略時設定）。

　［ロード］の「ACTIVATION」は、Beanがアクティブになった際にロードされ、DBに対する排他的アクセスを行います。「TRANSACTION」は、トランザクション開始時にBeanがロードされ、DBへは共有アクセスを行います。