基于文件的服务和并发问题

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

如果您确实需要直接写入文件系统，我建议您将服务对象与维护文件权限的服务上托管的对象进行对话，而不是让多个对象直接访问它。然后，您可以适当锁定该对象以保持一致性。