トランザクションのないデータベースで複雑なことをするつもりはありません。ほとんどの場合、使いやすい組み込みコマンドがあります。しかし、他の永続データを扱うようになると、トランザクション サポートを簡単に使用することができなくなります。いくつかの例は
非永続データであっても、例外に続いて作業ブロックを元に戻すと便利なことがよくあります。言語で得られる標準的なデータ構造はどれも、トランザクションをサポートしていません。
私が知りたいのは、なぜデータベースが特殊なケースなのですか?
データベース外のトランザクション動作のトピックへの有用なリンクはありますか?
私は敬意を表して反対しなければなりません：トランザクションシステムは自動的かつ排他的にデータベースエンジンではなく、まったく逆です...
データベーストランザクションとは異なるアプリケーショントランザクションメカニズム（.NET）を実装しました。実際にはかなり簡単です（単体テストスイートを含めて数時間の作業）。これは完全にC＃で記述されており、データベース機能やその他のコンポーネントに依存することはありません。しかし、最初にいくつかのコンテキスト...
この非データベーストランザクション機能は、EJB、ESB、JMSなど、多くの場合BPMに関連付けられている、Javaプラットフォーム上のいくつかのマニフェストに存在します。これらの症状のいくつかは、基礎となるデータベースを使用しますが、常にではなく、必要がないわけではありません。MSMQなど、他のプラットフォームにも同等の症状があります。
ほとんどのレガシーバージョン管理システムは、ACIDトランザクションセマンティクスを実装していません。ddaaが言ったように、CVSはそうではありませんが、Subversion（その後継）はそうします。VisualSourceSafeはそうではありません。Subversionを調査すると、これを示す比較チャートを見つけることができます。
ここで重要な点として、データベーストランザクションまたはそれに相当するものは、安全なビジネスロジックを保証するものではありません。私はSubversionが大好きですが、皮肉なことにこの事実の素晴らしい例です。
自動ビルドスクリプト（アプリケーションをコンパイル、テスト、パッケージ化する1つのコマンド）とともにSubversionを忠実に使用し、壊れたビルドをソース管理リポジトリにコミットすることができます。私はそれを繰り返し見ました。もちろん、VSSのような非ACIDトランザクションベースのソース管理ツールを使用するとさらに簡単になります。しかし、Subversionのようなツールでそれが可能であることを知ることは多くの人々にとって衝撃的です。
シナリオをレイアウトさせてください。あなたと同僚はアプリケーションを開発しており、ソース管理リポジトリにSubversionを使用しています。どちらもコーディングを行っており、リポジトリにコミットすることもあります。いくつかの変更を加え、クリーンビルドを実行し（すべてのソースファイルを再コンパイルし）、すべてのテストに合格します。だから、あなたはあなたの変更をコミットして家に帰ります。あなたの同僚は自分の変更に取り組んでいるので、クリーンビルドを実行し、すべてのテストに合格したことを確認して、リポジトリにコミットします。しかし、同僚はリポジトリから更新し、さらにいくつかの変更を加え、クリーンなビルドを実行すると、ビルドが彼の顔に吹き飛ばされます！彼は変更を元に戻し、リポジトリから再度更新し（念のため）、クリーンなビルドがまだ爆発していることに気付きました。同僚は、ビルドとソースのトラブルシューティングに次の数時間を費やします。そして最終的に、ビルドの失敗を引き起こしている、離れる前に行った変更を見つけます。彼はあなたとあなたの相互の上司に厄介な電子メールを送り、あなたがビルドを壊してから不注意に家に帰ったと不平を言いました。あなたは朝に到着し、同僚と上司があなたの机であなたを罵倒するのを待っているのを見つけます、そして他のみんなが見ています！したがって、クリーンビルドをすばやく実行し、ビルドが壊れていないことを示します（昨夜と同じように、すべてのテストに合格します）。
では、これはどのように可能ですか？各開発者のワークステーションがACIDトランザクションの一部ではないために可能です。Subversionは、リポジトリのコンテンツのみを保証します。同僚がリポジトリから更新したとき、彼のワークステーションには、リポジトリのコンテンツ（変更を含む）と彼自身のコミットされていない変更の混合コピーが含まれていました。同僚がワークステーションでクリーンビルドを実行したとき、彼はACIDセマンティクスによって保護されていないビジネストランザクションを呼び出していました。彼が変更を元に戻して更新を実行すると、ワークステーションはリポジトリと一致しましたが、ビルドはまだ壊れていました。なんで？ワークステーションは、リポジトリへのコミットとは異なり、ACIDセマンティクスによって保護されていない別のビジネストランザクションの一部でもあったためです。クリーンビルドを実行する前に、リポジトリに一致するようにワークステーションを更新していなかったため、リポジトリに存在していたソースファイルを実際にビルドしていませんでした。このような更新を実行すると、ワークステーションでもビルドが失敗することがわかります。
これで、最初のポイントについて説明できます。トランザクションには、慎重に検討する必要のあるスコープ/コンテキストがあります。ACIDトランザクションがあるからといって、ビジネスロジックが安全であるとは限りません。ただし、ACIDトランザクションのスコープ/コンテキストとビジネスロジックが完全に一致している場合を除きます。何らかの形式のデータベースACIDトランザクションに依存しているが、そのデータベーストランザクションでカバーされていないビジネスロジックで何かを行う場合、同等の壊滅的なエラーを引き起こす可能性のあるギャップがあります。ビジネスロジックをデータベーストランザクションと完全に一致させることができれば、すべてが順調です。そうでない場合は、おそらく別の商取引が必要です。保護されていないロジックの性質によっては、独自のトランザクションメカニズムを実装する必要がある場合があります。
したがって、メッセージングはトランザクションである可能性がありますが、スコープは単なるメッセージです。上記の例に関して、Subversionのコンテキストは、リポジトリへの個別のコミットのみです。ただし、ビジネストランザクションはクリーンビルドであり、はるかに広い範囲が含まれます。この特定の問題は通常、クリーンなビルドとクリーンなチェックアウトをスクリプト化することで解決されます。理想的には、継続的インテグレーションの実装を使用します（CruiseControlなどを使用）。開発者ワークステーションでは、各開発者は、クリーンビルドの前に、完全な更新（またはクリーンチェックアウト）を実行するための規律を行使する必要があります。
したがって、要約すると、すべてのトランザクションには、その保護を制限するスコープまたはコンテキストがあります。ビジネストランザクションには、通常使用するトランザクションメカニズム（データベースエンジンなど）の範囲を超えるロジックが組み込まれていることがよくあります。あなたは違いを補う必要があるかもしれません。まれに、そうするために独自のトランザクションメカニズムを作成することが理にかなっている場合もあります。
私は、控えめな90人の会社のために重要なビジネスシステムの書き直しを設計しました。そのようなメカニズムを実装する必要があると感じ、その経験は簡単で、価値があり、やりがいのあるものであることがわかりました。おそらくもう少し簡単にやり直しますが、なぜデータベーストランザクションだけに固執できないのか常に疑問に思います。
トランザクションがデータベースでしか見られない理由は、定義上、トランザクションを提供するシステムをデータベースと呼ぶからだと思います。それは循環しているように聞こえるので、詳しく説明する必要があります。
トランザクション サポートは、ACIDプロパティを提供する機能です。簡単に言えば、トランザクションとは、1. 全体として成功するか、全体として失敗するかのいずれかである 1 つのパッケージに多数の個別の操作をバンドルすることを可能にするものであることを意味します。システムの「一貫した」ビューを常に持っています。
ファイルシステムは伝統的に何らかのロック機構を提供していますが、これはトランザクションの提供とは異なります。ただし、すべてのファイルシステムにはいくつかのアトミック プロパティがあります。たとえば、ディレクトリ/a/とがあり/b/、 と を同時に実行しようとするmv /a /b/aとmv /b /a/b、整合性を損なうことなく、これらの操作の 1 つだけが成功します。ただし、一般にファイルシステムに欠けているのは、複数の操作を 1 つの分離されたアトミック バンドルにバンドルする機能です。
答えはSubversionに言及しました。すべての正常なバージョン管理システムにはトランザクションがあります。複数のファイルにコミットすると、システムはコミットを完全に適用するか、完全に拒否します (CVS を除いて、私は正気ではないと思います)。拒否の原因は常に同時変更です。バージョン管理システムの実装者は、データベースの維持を非常に意識しています。
別の回答では、メッセージング システムはトランザクショナルであると言及されていました。リンクされた資料は読みませんでしたが、回答自体には、メッセージのアトミック配信のみが記載されていました。それは取引ではありません。
Brian C.がここで言及するまで、私はClojureについて聞いたことがありませんでした。データベースのコンテキスト外のトランザクションの実装であるように私には思えます。ここでは、耐久性のあるデータの一貫性を維持することよりも、同時実行制御に焦点を当てています。
したがって、Clojure を除いて、トランザクションを必要とするシステムはすべて、基礎となるデータベースを使用するか、それ自体をデータベースに変えるようです。
最新のファイル システムにはトランザクションがあります。それらはエンドユーザーに対して透過的です。
いくつか例を挙げると、NTFS、XFS、JFS、EXT3、および ReiserFS はすべて対応しています。
そして、それはファイルシステムの内部にすぎません。多くの OS は、排他的 (書き込み) ロックと共有 (読み取り) ロックによるファイル ロック (たとえば、*NIX の世界では flock(2) を参照) もサポートしています。
編集：考えてみると、ファイルシステムには最新のDBのような分離レベルはありません。ファイルの読み取りが完了すると、ロックしていない場合は伝統的にファイルを閉じるからです。その後、書き込みたいときに再度開きます。
ClojureはSoftware Transactional Memoryを使用します。これは、トランザクションを使用して、手動ロックなしでマルチスレッド プログラムを簡単かつ安全に作成できるようにします。Clojure には変更可能な参照を持つ不変のデータ構造があり、参照を変更するにはトランザクションが必要です。
メッセージング システムは、トランザクション リソース マネージャーのもう 1 つの例です。
つまり、メッセージ コンシューマがキューからのメッセージを正常に処理することを保証できます。処理が失敗した場合、メッセージはキューに残されます。
さらに、メッセージング システムは、別のリソース マネージャーとの分散トランザクションに参加できます。
詳細はこちら
Subversion コミットはトランザクショナルです: 真にアトミックであるため、コミットが中断されても、リポジトリが一貫性のない状態のままになることはありません。
ファイルシステムとデータベースを1つのトランザクション単位として扱う必要がある状況がありました。
私の場合、ファイルシステムにファイルのセットをダウンロードするだけで済みました。毎回ランダムなディレクトリを作成し、そこにデータを配置し、ディレクトリ名をデータベーステーブルに保存することでそれを行いました。したがって、すべてのデータベース作業、およびデータベーステーブル内のディレクトリ名（=ファイルシステム作業）は、1つのデータベーストランザクションで実行できます。
http://www.databasesandlife.com/atomic-operations-over-filesystem-and-database/