我正在從事一個在線文件管理項目，其中我們在數據庫（sql server）上存儲引用，並在文件系統上存儲文件數據;其中我們面臨着文件系統和數據庫之間協調問題我們正在上傳一個文件，並且還刪除了一個文件，這個文件首先在數據庫中創建一個引用或者在文件系統上存儲文件;問題是如果先在數據庫中創建引用，然後將文件存儲在文件上system.bur在文件系統上存儲文件時會發生任何類型的錯誤，然後在數據庫中創建該文件的引用，但在文件系統上沒有文件數據。請給我一些解決辦法，如何處理這種情況;我非常需要它;; 和原因？如何保證跨兩個數據庫（文件系統和RDBMS）的原子性？
這實際上比您想象的要容易一些。
首先，您需要確定「單一來源的真相」。
也就是說，無論文件系統還是數據庫在任何給定時間點都是正確的，哪一個是它？
其原因是它更容易解決衝突。
您應該假定數據庫是您的源，並且文件系統是數據庫的陰影。這似乎與直覺相反，因爲如果數據庫不在文件系統中，數據庫中如何存在條目。顯然它不能。但是，基本上，如果文件不在數據庫中，那麼「反正它不存在」。所以，文件系統反映了數據庫的狀態，而不是反過來。
鑑於這些假設，您最終得到這些衝突解決規則。
對於任何給定的文件：
File Exists DB Entry Exists Action
Yes Yes No action, normal state
No Yes Error -- missing file, "should never happen"
No No No action, normal state
Yes No Delete the file, but no error.
如果您上傳文件，有存在一個灰色地帶 - 即當一個文件被上傳而是由DB尚未確認。
要解決此問題，您需要在暫存模式下上載文件。
一個簡單的方法是將文件上傳到不同的目錄，但在同一物理文件系統上，或使用臨時文件名將其上傳到最終位置。無論哪種方式，該文件都可以通過名稱或位置輕鬆識別爲「正在處理」。
由於兩個原因，您希望在同一個文件系統上擁有此文件「staged」。一，磁盤空間。如果上傳時磁盤沒有填滿，那麼你知道它會安裝在最後的安放地點（它已經「保留」了空間）。二，當你最終放置文件時，該操作必須是原子的。在同一個文件系統上進行文件重命名操作，在現代文件系統上是原子的。基本上，即使不可避免地「覆蓋」現有文件（在重命名操作期間刪除原始文件），也不能將文件「半途更名」。
一旦上演，你的操作變得：
Start DB transaction
Rename file
Add DB record
Commit transaction
如果重命名文件操作失敗，則中止並回滾事務數據庫，從而進入。如果重命名成功，並且數據庫失敗？然後你有上面列出的狀態＃4。重試上傳，直到成功。
要刪除一個文件，這樣做：
Start DB Transaction
Delete DB record
Commit transaction
Delete file from file system
如果DB刪除失敗，你不刪除該文件。如果數據庫刪除成功，並且文件刪除失敗，那麼我們又回到了＃4狀態。
最後，您有一個收割過程，定期（每天，每週，無論）將數據庫與文件系統進行比較，刪除任何不在數據庫中的文件。由於數據庫是「單一事實來源」，兩家商店最終將同步。
如果文件丟失，有一個數據庫記錄，那麼你有「數據損壞」。不要這樣做。這是一個錯誤，或者有人在你的文件系統上行走。
上傳過程的重試特性和刪除過程的快速失敗爲您提供了僞兩階段提交過程，可以輕鬆檢查正確與錯誤以及容易糾正到正確的狀態。
您需要一個同時支持數據庫和文件系統事務的事務協調器才能使two phase commit這樣工作。
你沒有指定數據庫，編程語言或平臺，所以這是儘可能多的答案。
在Windows Vista，Windows Server 2008或更高版本的Windows操作系統中，您可以登錄use transactions to govern access to the NTFS。
使用此工具，如果您要在.NET中編程，則可以使用System.Transactions命名空間對文件系統執行更新，並對數據庫執行更新（作爲一個原子單元）。
我不知道其他操作系統上是否有事務性文件系統。這並不意味着它們不存在。
Duplicate：http://stackoverflow.com/questions/2524899/how-to-bring-coordination-btween-file-system-and-databse – NealB 2010-03-26 19:07:38