データベースの開発者にとって、トランザクションの行為は簡潔に説明するのは難しいです。しかし、ユーザーにとっては、わかりやすく説明する必要があります。そのため、最も簡単で理解しやすい表現は「厳密な直列化」という言葉です。なぜならば、語彙の直列化の定義は肯定式です。
様々なデータベースは、自身が可直列化をサポートしていると主張していますが、実際にはユーザーに使用しやすさを感じさせることを意図しています。なぜならば、直列化以外の行為はあいまいすぎる。
トランザクションの行為の定義として最も広く受け入れられているのは ANSI SQL です。私も学生時代にデータベーストランザクションがそのように定義されていると認識していました。その中で、一番問題は否定式の定義です。「何が起こらない場合は、何です」そういうロジカル普段には通じない。考えておく、「Dirty Read」、「Non-Repeatable Read」そして「Phantom Read」を防ぐなら、語彙の直列化ですか。否、その後の研究で他の非直列化の異常があると指示された。個人的な意見ですが、語彙の直列化以外の直列化は、定義の不足を利用した小賢さに過ぎません。
どうして、データベースは肯定式の定義に採用しないか。私は以前、データベース開発者として肯定式の定義を書く努力をしました。最後でその件を辞める原因はこの肯定式の定義を理解するのは難しい。データベースのユーザーは学術の専門家ではありません、もしデータベースのマニュアルは文人ぶるの感じなら、結構読みにくくなります。個人の理解は、厳密な直列化以下の一貫性と独立性の理解は難しい過ぎて、メモリーモデルと似たような感じ。
なら、どうしてデータベースは厳密な直列化以外を提供しますか。理由は性能です、直列化を破ることで、大幅なパフォーマンスが上がります。その場合、トランザクションの一貫性と独立性は「矢を放ち後から的を描く」ようなものになります。あるデータベースは for update 構文と提供している、そして、ユーザーは自分の要求からその構文を使用する。その構文のおかけで、全般のツーフェーズロックを避けることができます。
一部のクエリでは、データをそのまま利用する必要があります。また、複数のクエリが同じデータを変更せずに利用する必要がある場合もあります。例えば、外部キーの親テーブル。変更せずのため、シェアロックが作られた。
そこまで、トランザクションの行為は段々複雑になって、どう理解すればいいという問題が現れる。昔、x86プラットフォームのメモリーモデルを理解するために、Total Store Order (TSO) というモデルが提案されました。同様に、トランザクションの理解には、データベース内部な動作方法を少し理解する必要があります。
今のデータベースほぼ全部 MVCC を受け入れる、そして、snapshot という概念が出る。snapshot のおかげで、書くことは新しいバージョンになって、元のバージョンはまだ読むことができます。snapshot 自身は理解しやすくて、いつも同じバージョンが読んでいる。
そこまでの話がりかいしたら、ANSI SQL の定義を切り捨てでも大丈夫だと思う。厳密なツーフェーズロックではない場合、トランザクションの行為は一言で言いにくくて、少し snapshot モデルで思考すれば、アプリの開発ところも気軽になりますかも。