WebSphere Application Server for z/OS, Version 6.0.x   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

並行性制御

並行性制御は、データ・リソースの競合の管理です。 並行性制御スキームは、 データ・アクセス・トランザクションで指定されたリソースを最初にロックして、 トランザクションが終了するまでそれを解放しない場合、ペシミスティック であると見なされます。 並行性制御スキームは、 ロックが獲得され、 トランザクションの終了時の非常に短期間にリリースされる場合、オプティミスティック であると見なされます。

オプティミスティック並行性の目的は、 指定されたリソースが、 他のトランザクションによって使用できなくなる時間を最小限にすることです。 これは、 実行時間の長いトランザクションでは特に重要なことで、 こうしたトランザクションは、ペシミスティック・スキームの下では、 容認できないほど長時間にわたってリソースをロックします。

オプティミスティック・スキームでは、 ロックは、読み取り操作の直前に取得され、 直後に解除されます。 更新ロックは、更新操作の直前に取得され、 そのトランザクションが終了するまで保持されます。

この製品で、 オプティミスティック並行性を使用可能にするには、 過剰更新スキーム を使用して、 現行トランザクションの開始以降に、 基礎をなすデータ・ソースに対して別のトランザクションによる更新が行われているかどうかをテストします。 このスキームを使用して、 更新用にマークされた列およびそれらの元の値は、UPDATE ステートメントの WHERE 文節で明示的に追加されるので、 基礎をなす列の値が変更された場合、 ステートメントは失敗します。 結果として、 このスキームは列レベルの並行性制御を提供することができます。 ペシミスティック・スキームは、 列レベルでのみ並行性を制御できます。

オプティミスティック・スキームは、通常、 このタイプのテストをトランザクションの最後にのみ実行します。 トランザクションの開始以降、 基礎をなす列が更新されていない場合は、 コンテナー管理パーシスタンス・フィールドに対する更新の保留はコミットされ、 ロックが解放されます。 ロックが獲得できないか、 あるいは現行トランザクションの開始以降、 他のトランザクションが列を更新している場合、 トランザクションはロールバックされます。 トランザクション内で実行された作業はすべて失われます。

ペシミスティックおよびオプティミスティック並行性スキームは、 異なるトランザクション分離レベルを必要とします。 同じトランザクションに参加していて、 別の並行性制御スキームを必要とするエンタープライズ Bean どうしは、 基礎をなす同じデータ接続では動作できません。

ベスト・プラクティス: オプティミスティック並行性を使用するかどうかは、トランザクションのタイプによって決まります。 失敗するとペナルティーの高いトランザクションの場合は、ペシミスティック・スキームで管理するほうが良いかもしれません。 (ペナルティーの高いトランザクションのリカバリーは、 危険度が高いかリソース集約型となります。) ペナルティーの低いトランザクションの場合は、 ほとんどの場合、失敗のリスクを冒してでもオプティミスティック・スキームを使用して効率の向上 を図ってみる価値があります。 通常、更新の衝突があまり頻繁に発生しないと予想される場合は、 オプティミスティック並行性のほうが有効であり、 更新の衝突が頻繁に発生すると予想される場合は、 ペシミスティック並行性のほうが有効になります。 bprac



関連概念
ロック・アップグレードが原因のデータベース・デッドロック
関連タスク
アクセス・インテント・ポリシーの使用
関連資料
アクセス・インテント -- 分離レベルおよび更新ロック
エンタープライズ Bean: 学習用リソース
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:52:11 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cejb_cncr.html