基於文件的服務和併發問題

Question

我正在設計一組WCF服務的體系結構。由於部署這些服務的性質（遠程部署到客戶端站點上的許多不可管理的系統上，因此我們無法承擔數據庫服務器的管理開銷），數據存儲必須基於文件（我們正在傾向於用於文件格式的XML）。

服務的性質再次意味着單個文件中存在併發問題的可能性，並且我試圖想出一個系統，該系統在所有情況下都將正確運行，並避免嘗試在那裏讀取數據是掛起的寫入操作。

我目前的想法是採取兩種可能的路線之一。

1. 鎖定文件

   這將通過以下方式進行操作。 所有的文件操作都會有一個鎖定機制。讀取將檢查以確保在請求數據之前所需的文件當前未被鎖定。如果文件被鎖定，服務應該休眠幾毫秒（在尚未確定的範圍內）。寫入操作將設置鎖定，提交數據，然後解鎖文件。在後臺

2. 額外的程序提供數據服務

   這個版本會在後臺輔助應用程序，揭露各種公共靜態方法，通過服務調用。後臺應用程序將全權負責維護數據的內存中表示，向服務提供數據，並使文件副本與內存對象保持同步。在這方面，它的行爲就好像它是一個交易化數據庫服務器。

實現創建這些類型的服務，其中選擇將提供併發衝突的機會最小最大性能爲目標的兩個（或其他可能的）方法嗎？選項1設計的簡單性意味着我更喜歡那個選項，但我擔心由於「睡眠」操作而導致性能可能受損。

Answer 1

我知道你說你不想管理數據庫服務器的開銷，但爲什麼不使用SQL Express之類的東西。您只需要安裝運行時。同樣的事情會說使用Access數據庫文件。只需要一個運行時間。然後，您可以繞過這些其他問題，並且可以確保將運行時作爲安裝程序所需組件的一部分。我認爲這會讓你的生活更加輕鬆，並且不會有真正的數據庫服務器的開銷。

另一種選擇是像SQL Lite那樣。它只需要將一些dll部署到您的應用程序中。根本沒有任何開銷，但有一個分貝必須自己管理所有文件訪問的好處。

SQL Lite，MySQL甚至SQL Express都小巧輕便，足以用作手持設備上的數據存儲，所以我不明白爲什麼類似的東西在這裏不起作用。

Answer 2

我要把約翰·桑德斯評論到一個答案：

這很可能是這兩個選項會變成需要比簡單的安裝了SQL Express的更多的管理開銷。

您可以從安靜安裝和附加數據庫文件等桌面型功能中獲益。

關於1），如果文件被鎖定時發生崩潰會發生什麼？

Answer 3

結賬SQL Server Compact edition。它不需要任何正在運行的服務並支持XCopy部署。

Answer 4

數據庫是對一組文件的抽象。他們要求你以一小部分成本重新發明車輪。我認爲你真的需要回顧這一點，並解釋試圖編寫自己的數據庫的業務影響 - 這將花費更長的時間，成本更高，並且不太可靠。

Answer 5

如果您確實需要直接寫入文件系統，我建議您將服務對象與維護文件權限的服務上託管的對象進行對話，而不是讓多個對象直接訪問它。然後，您可以適當鎖定該對象以保持一致性。