2相ロック編集

2相ロックプロトコルによると、トランザクションの実行中に、2つの明確で連続した相でそのロックを処理する:

  1. 拡張相(別名成長相):ロックが取得されるが解放しない(ロックの数は増加するだけ)。
  2. Shrinking phase (aka Contracting phase): ロックが解放され、ロックは獲得されない。

2段階のロック規則を要約すると、ロックが解放された後は決してロックを獲得してはいけないということである。 6487>

通常、フェーズ1の終了時にトランザクション内で明示的な知識がなければ、トランザクションが処理を完了し、コミットを要求したときにのみ安全に判断されます。 この場合、すべてのロックを一度に解放することができます(フェーズ2)。

保守的な2フェーズロックEdit

2PLとC2PLの違いは、C2PLのトランザクションは、トランザクションが始まる前に必要なすべてのロックを取得する点です。 これは、すでにいくつかのロックを保持しているトランザクションが、他のロックを待つためにブロックしないようにするためです。 保守的な2PLはデッドロックを防ぐ。

Strict twophase lockingEdit

S2PLプロトコルに準拠するには、トランザクションは2PLに準拠し、終了後、つまりコミットまたは中止された後にのみ書き込み(排他)ロックを解放する必要がある。 一方、読み取り(共有)ロックはフェーズ2の間、定期的に解放される。 このプロトコルはB-treeではボトルネックの原因となるため適切でない(B-treeは常に親ルートから検索を開始する)。 つまり、実行が完了し(ready)、コミットまたはアボートされた後にのみ、トランザクションによって適用された書き込み(排他的)および読み込み(共有)ロックを解放します。 このプロトコルは、S2PL規則にも準拠している。 SS2PLに従うトランザクションは、トランザクションの実行期間全体が続くフェー ズ1を持ち、フェーズ2がない(または縮退したフェーズ2)と見なすことができる。 したがって、実際には1つのフェーズしか残っておらず、2PLから歴史的に発展した概念であることと、2PLがスーパークラスであることから、名称に「2フェーズ」がまだ利用されているようです。 スケジュールのSS2PL特性は、Rigorousnessとも呼ばれます。 この性質を持つスケジュールのクラスの名前でもあり、SS2PLスケジュールは “Rigorous Schedule “とも呼ばれる。 厳密性 “という用語は、”二相 “という不要な遺産から解放され、またどの(ロック)機構にも 依存しない(原理的には他のブロック機構を利用できる)。 この特性のそれぞれのロック機構は、Rigorous 2PLと呼ばれることがある。

SS2PLはS2PLの特別な場合であり、すなわち、スケジュールのSS2PLクラスはS2PLの適切なサブクラスである(すべてのSS2PLスケジュールはS2PLスケジュールでもあるが、SS2PLでないS2PLスケジュールも存在する)。

SS2PLはほとんどのデータベースシステムで選ばれた並行制御プロトコルで、1970年代のその初期から活用された。 多くの状況で効果的なメカニズムであることが証明されており、シリアライザビリティの他に、効率的なデータベース回復に役立つストリクトネス (カスケードレスリカバビリティの特殊ケース) や、COベースの分散シリアライザビリティおよびグローバルシリアライザビリティソリューションが採用されている分散環境でのコミットメント順序付け (CO) も提供されています。 COのサブセットである分散SS2PLは、分散ロックマネージャ(DLM)を必要とせず、分散デッドロック(後述)が自動的に解決される効率的な実装となっています。 マルチデータベースシステムに SS2PL を採用することで,大域的な直列化可能性 を確保することは CO の発見以前から知られていましたが,CO の登場により,アトミック コミットメントプロトコルが大域的な直列化可能性を維持する役割を理解し,さらに 自動的に分散デッドロックを解決することを確認しました (Distributed SS2PL の詳細な例を参照) . 実際,SS2PLがRecoverabilityとCOの性質を継承していることは,2PLのサブセットであることよりも重要です.2PLはそれ自体,一般的な形で,単純な直列化メカニズム (ただし直列化もCOによって暗示される) を構成していますが,SS2PLに他の重要な性質を与えているとは知られていません. 2PLは、その一般的な形でも、Strictnessと組み合わせた場合、すなわち、Strict 2PL (S2PL)でも、実際に利用されることは知られていない。 一般的なSS2PLは,2PLやS2PLのように「フェーズ1の終了」を示す必要がないため,実装がより簡単である. また、一般的な2PLと異なり、SS2PLは前述のように有用なStrictnessとCommitmentの順序付け特性を提供する。

SS2PLの多くの変形が存在し、トランザクション中にロックタイプを変更する場合を含む様々な状況下で様々なセマンティクスでロックタイプを利用することが可能である。

  1. SS2PL vs. S2PL: どちらもSerializabilityとStrictnessを提供します。 S2PLはSS2PLのスーパークラスなので、原理的にはより多くの並行性を提供するかもしれません。 しかし、一般的に並行性の利点はありませんし(両者で全く同じロックが存在し、S2PLではロック解放が実質的にそれほど早まらない)、トランザクション終了とは別にS2PLでフェーズ1の終了メカニズムを扱うオーバーヘッドも正当化されません。 また、SS2PLはCommitment orderを提供しますが、S2PLは提供しません。 4026>
  2. 特に1990年以前、あるいはそれ以降、多くの論文や書籍、例えば(Bernstein et al. 1987, p. 59)では、「Strict 2PL (S2PL) 」という用語は、SS2PLのプロトコルである「Release all locks only after transaction end」によって頻繁に定義されてきた。 したがって、”Strict 2PL “は、SS2PLプロトコルが生成するクラスよりも大きいStrictnessと2PLの交点の名前であることはあり得なかったのです。 このため、混乱が生じました。 S2PLをStrictnessと2PLの交点として明示的に定義し,SS2PLの新しい名前をつけ,S2PLとSS2PLのクラスを明示的に区別することによって,論文 (Breitbart et al. 1991) と (Raz 1992) は混乱を解消しようとした.”
  3. SS2PLよりも一般的な性質として、スケジュール・スーパークラスであるStrict commitment ordering (Strict CO, or SCO)があり、これも直列化可能性と厳密性、COを提供し、同様のロック・オーバーヘッドを持っています。 SCOはSS2PLと異なり、コミット遅延の可能性を代償に、読み書きの競合時にブロックしない(読み込みロックは書き込みロックの獲得をブロックしない。SCOとSS2PLは書き込み読み込みと書き込みの競合時に同じ動作をする)ため、このような競合タイプではSCOはSS2PLより平均トランザクション完了時間が短く、性能が良い。 SS2PLは上記のロック互換性テーブルに従いますが、SCOは以下のようなテーブルを持っています。

Lock type

write-lock

Lock compatibility for SCO
Lock type read-lock write-lock
read-> write-lock read-lock
write-lock X

なお、SCOはトランザクション終了時にすべてのロックを解放し2PLロック規則に従っていますが、このロックは2PLロック規則には従っています。 SCOはロック互換テーブルが異なるため、2PLのサブセットではありません。 SCOはフェーズ1で2つのトランザクション間の物質化された読み書き競合を許しますが、2PLはフェーズ1では許しません(シリアライザビリティの物質化競合についてを参照してください)。 一方、2PLはフェーズ2において、SCOが全く許容しない他の実体化された競合タイプを許容する。 このことから、スケジュールクラス2PLとSCOは比較不可能であることがわかります(つまり、どのクラスも他のクラスを含まないということです)。

Summary – Relationships among classesEdit

Schedule classes containment: クラスAからクラスBへの矢印は、クラスAがBを厳密に含むことを示し、クラス間の有向パスがない場合は、クラスが比較不可能であることを意味します。 ある性質が本質的にブロッキングであるとは、他のトランザクションで特定のイベントが発生するまでトランザクションのデータアクセス操作をブロックすることによってのみ実施可能な場合をいう。 (Raz 1992)

共通のスケジュールを持つ任意の2つのスケジュールクラス(それらのスケジュールのそれぞれの特性によって定義される)間で、どちらかが他方を含む(それらが等しくない場合は厳密に含む)か、それらが分離不可能である。 2PLクラスと他の主要なスケジュールクラス間の包含関係を以下の図にまとめました。 2PLとそのサブクラスは本質的にブロッキングであり、そのために楽観的な実装は存在しません(「楽観的2PL」が言及されるときはいつでも、それは2PLクラス内のスケジュールも含むクラスを持つ別のメカニズムを指します)

Articles

コメントを残す

メールアドレスが公開されることはありません。