Файловые службы и проблемы параллелизма - PullRequest
1 голос
/ 17 декабря 2009

Я проектирую архитектуру для набора служб WCF. Из-за характера развертывания этих сервисов (удаленно развернутых на нескольких неуправляемых системах на клиентских сайтах, поэтому мы не можем позволить себе административные издержки серверов баз данных), хранилище данных должно основываться на файлах (мы довольно сильно склоняемся к XML для формата файла).

Еще раз, природа сервисов означает, что существует вероятность проблем параллелизма в отдельных файлах, и я пытаюсь найти систему, которая будет вести себя корректно во всех случаях и избегать попыток чтения данных, когда есть ожидающая операция записи.

Мое нынешнее мышление выбирает один из двух возможных путей.

  1. блокировка файлов

    Это будет работать следующим образом. Все файловые операции будут иметь механизм блокировки. Чтения будут проверять, чтобы убедиться, что требуемый файл в настоящее время не заблокирован, прежде чем запрашивать данные. Если файл заблокирован, служба должна находиться в спящем режиме в течение случайного числа миллисекунд (в пределах пока неопределенного диапазона). Операции записи устанавливают блокировку, фиксируют данные и затем разблокируют файл.

  2. дополнительная программа в фоновом режиме для предоставления данных сервисам

    Эта версия будет иметь вторичное приложение в фоновом режиме, предоставляя различные общедоступные статические методы, вызываемые сервисами. Фоновое приложение будет нести единоличную ответственность за поддержание представления данных в памяти, предоставление данных службам и синхронизацию копий файлов с объектами в памяти. В этом отношении он будет вести себя так, как если бы это был сервер баз данных с транзакциями.

Из двух (или, возможно, других) методов реализации цели создания таких сервисов, какой вариант обеспечит наибольшую производительность с наименьшей вероятностью конфликтов параллелизма? Простота конструкции варианта 1 означает, что я больше поддерживаю этот вариант, но я обеспокоен тем, что производительность может пострадать в результате операций "сна".

Ответы [ 5 ]

1 голос
/ 17 декабря 2009

Я превращу комментарий Джона Сондерса в ответ:

Вполне вероятно, что оба варианта потребуют больше административных затрат, чем простая установка Sql Express.

Вы можете воспользоваться преимуществами настольных функций, таких как тихая установка и вложенные файлы БД.

Что касается 1), что произойдет, если произойдет сбой, когда файлы заблокированы?

1 голос
/ 17 декабря 2009

Я знаю, что вы говорите, что не хотите административных накладных расходов для серверов баз данных, но почему бы вам просто не использовать что-то вроде SQL Express. Все, что вам нужно, это установленная среда выполнения. То же самое можно сказать и об использовании файла базы данных Access. просто нужно время выполнения. Затем вы можете обойти эти другие проблемы и просто убедиться, что у вас есть среда выполнения в составе необходимых компонентов вашего установщика. Это, я думаю, сделало бы вашу жизнь намного проще, и у вас не было бы издержек реального сервера БД.

Другим вариантом будет что-то вроде SQL Lite. Требуется только пара DLL, развернутых с вашим приложением. Никаких накладных расходов, а только наличие базы данных по сравнению с необходимостью управлять всем доступом к файлу самостоятельно.

SQL Lite, MySQL и даже SQL Express являются небольшими и достаточно легкими, чтобы их можно было использовать в качестве хранилищ данных на переносных устройствах, поэтому я не понимаю, почему что-то подобное не будет работать здесь.

0 голосов
/ 17 декабря 2009

Если вам действительно нужно писать напрямую в файловую систему, я бы порекомендовал вам, чтобы ваши сервисные объекты общались с объектом, размещенным в сервисе, который поддерживает права доступа к файлу, вместо того, чтобы несколько объектов напрямую обращались к нему. Затем вы можете соответствующим образом заблокировать этот объект для обеспечения согласованности.

0 голосов
/ 17 декабря 2009

База данных - это абстракция над набором файлов. Они просят вас заново изобрести колесо за небольшую плату. Я думаю, что вам действительно нужно отодвинуть это назад и объяснить влияние на бизнес попыток написать собственную базу данных - это займет больше времени, будет стоить дороже и будет намного менее надежным.

0 голосов
/ 17 декабря 2009

Оформить SQL Server Compact edition . Он не требует никакой работающей службы и поддерживает развертывание XCopy.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...