「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 「アクセス・インテント」ポリシー | |||
- wsPessimisticUpdate
これを指定した場合、「SELECT …… FOR UPDATE」文が使用され、DBの行の更新ロックが獲得される - wsPessimisticUpdate-WeakestLockAtLoad
省略時の値として使われる。データをロードする際に、EJBコンテナは、ターゲットのDBの「weakest lock」を使用する。つまり、行は共有ロックされる。更新が必要になった場合に、更新ロックが獲得される - wsPessimisticUpdate-NoCollision
「Read Committed」が使用され、行のロックは獲得ない（「SELECT …… FOR UPDATE」を使用しません）。従って、同じ行に対して、同時更新がされないことを確信できない場合には使用を避けるようにする - wsPessimisticUpdate-Exclusive
DB分離レベルの「Serializable」が使用され、データのロード時に「SELECT …… FOR UPDATE」が使用される - wsPessimisticRead
Entity Beanが読み込み専用である場合に使用する。「Repeatable Read」が使用される - wsOptimisticUpdate
「Optimistic Locking Strategy」を使用したEntity Beanの更新に使用する - 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」を指定した例です。
図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」のいずれかを指定します。
- 「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）。
［Beanのキャッシュ］の設定で、［アクティブ化］と［ロード］の組み合わせで決定されます（表4）。
| コミット・オプション | アクティブ化 | ロード |
|---|---|---|
| Option A | ONCE | ACTIVATION |
| Option B | ONCE | TRANSACTION |
| Option C | TRANSACTION | TRANSACTION |
| 表4 コミット・オプションの指定 | ||
［アクティブ化］の「ONCE」は、Beanが最初にアクセスされた際にアクティブになります。「TRANSACTION」は、トランザクション開始時にアクティブになります（省略時設定）。
［ロード］の「ACTIVATION」は、Beanがアクティブになった際にロードされ、DBに対する排他的アクセスを行います。「TRANSACTION」は、トランザクション開始時にBeanがロードされ、DBへは共有アクセスを行います。
Copyright © ITmedia, Inc. All Rights Reserved.