Я очень мало знаю о файловых системах DFS, но столкнулся с проблемой в одном из наших развертываний.
Наше приложение записывает файлы в указанное место, закрывает их, а затем записывает запись в базу данных. Другая часть приложения берет эти записи БД и читает ранее записанный файл.
В некоторых случаях читатель получает сообщение «файл не найден», и это не удается. Перезапустите его, не касаясь чего-либо еще, и он правильно найдет файл, и все в порядке.
Я считаю, что исключил проблему с нашим приложением, поскольку файл определенно очищается / закрывается перед созданием записи в базе данных.
Поэтому я убежден, что операционная система или файловая система задерживают запись файла изнутри, поэтому он не доступен сразу.
Речь идет о файловой системе Windows 2003 SP2 DFS. Это вероятный сценарий с этой DFS? Если да, то можно ли переключить его на какую-то политику сквозной записи / без кеширования, чтобы файлы записывались быстро?
DFS - это распределенная файловая система, о чем и говорит название: «виртуальный» файловый ресурс, который распределяется и реплицируется на нескольких серверах. Каждый раз, когда ваше приложение записывает в него данные, оно фактически обращается к одной из своих копий на одном из серверов, которые являются его частью, и если другое приложение попытается прочитать те же данные вскоре после этого, оно вполне может получить доступ к другому серверу, который не сделал этого. Пока не получаю обновленных данных.
С DFS вы никогда не можете быть абсолютно уверены, что записанные в нее данные будут доступны при последующем чтении: всегда быть задержкой репликации; у вас также нет никакого способа указать вашему приложению «разговаривать» с конкретным сервером DFS: вы можете бесплатно подключиться к любому из серверов, на которых оно запущено.
Если вы хотите, чтобы это приложение работало в реальном времени, вам следует использовать стандартный файловый ресурс, а не DFS.
Вы делаете распространенное, но неверное предположение, что существует одно универсальное понятие «после» и что если вы будете делать одно «после» другого, вы гарантированно увидите последствия. Это просто ложное представление, и ничто из того, что вы можете сделать, никогда не заставит его работать так, как вы ожидаете.
Аналогия: отправить кому-то письмо, получить ответную квитанцию, позвонить человеку по телефону и предположить, что он должен прочитал письмо.
Как вы упомянули, отложенная запись все испортит. Многие другие вещи тоже могут его испортить. Пытаться найти все возможные способы поломки и исправить их все - просто безумие.
Вместо этого, если вам нужно упорядочить между операциями, используйте что-то, что специально гарантировано для обеспечения нужного вам порядка. Поскольку нет гарантированного упорядочения между файловой системой и базой данных, этого не будет.
Большинство файловых систем действительно обеспечивают гарантированный порядок относительно самих себя и своих собственных операций при доступе через процессы, запущенные в одном экземпляре операционной системы. Итак, после того, как файл настроен правильно, вы можете создать «триггерный» файл в той же файловой системе. Если читатель видит файл триггера, он может знать, что файл данных полный и действительный. Когда это будет сделано, он может удалить файл триггера.