私はオンラインファイル管理プロジェクトに取り組んでいます。データベース（SQLサーバー）に参照を保存し、ファイルシステムにデータをファイルします。
ファイルのアップロード中およびファイルの削除時に、ファイルシステムとデータベース間の調整の問題に直面しています。まず、データベースに参照を作成するか、ファイルシステムにファイルを保存します。
問題は、最初にデータベースに参照を作成してからファイルシステムにファイルを保存したが、ファイルシステムにファイルを保存しているときに何らかのエラーが発生した場合、そのファイルの参照はデータベースに作成されますが、ファイルは作成されないことです。データはファイルシステムに存在します。
そのような状況に対処する方法を教えてください。私はそれをひどく必要としています。
このケースは、ファイルを削除しているときにも発生しますか？
ファイル システムへのアクセスは実際にはトランザクションではありません。オール オア ナッシングの分散トランザクションを自分でシミュレートする必要があります。データベースでのコミットが失敗した場合は、ファイル システムのファイルを削除します。逆に、ファイルの書き込みに失敗した場合は、データベース トランザクションをロールバックします (これは少し複雑になりますが、大まかなスケッチです)。
ファイルが更新されると、かなり複雑になる可能性があることに注意してください。ファイルを上書きした後にデータベース トランザクションが失敗した場合でも、古いバージョンのファイルを復元できるように、最初にそれをコピーする必要があります。これを行うかどうかは、必要な堅牢性のレベルによって異なります。
すべての操作(ファイルの作成、書き込み、削除) がアプリケーションを通過するように強制してください。これを行うことができず、ファイルがファイル システム上で直接アクセスされるのを防ぐことができない場合 (および削除される可能性がある場合)、データベースをファイル システムと定期的に同期する以外に方法はありません。どのファイルが削除されたかを確認して削除します。データベースのエントリ。そのために、 X分ごとに実行するジョブを作成できます。
ファイルのハッシュ(MD5 など) をデータベースに保存することもお勧めします。計算には少し時間がかかりますが、これは問題を検出するのに非常に役立ちました。たとえば、エラーによってファイル システムでファイルの名前が変更されたが、データベースでは変更されなかった場合などです。これにより、定期的に整合性チェックを実行して、何も問題がないことを確認することもできます。
このアプローチが不十分な場合 (より堅牢にしたい場合など)、バイナリをデータベースの LOB に格納する以外に方法はありません。そうすれば、本当にトランザクション的で安全になります。
私が知っている古い質問ですが、他の読者の利益のために：
オペレーティング システムによっては、Transactional TxF を使用できる場合があります。
FILESTREAMは、まさにこの問題に対処するために SQL Server 2008 で導入されました。
ただし、それには独自の一連の実装上の課題があります。
2 つのイベント (参照の管理とファイルの管理) を 1 つのトランザクションとして扱います。どちらかが失敗した場合は、もう一方を元に戻します。そうすれば、2 つが同期していない状況に陥りにくくなるはずです。ファイルシステム操作よりもデータベース操作をロールバックする方が簡単です。