Gravação atrasada do Windows DFS

Question

Eu sei muito pouco sobre sistemas de arquivos DFS, mas encontrei um problema com uma de nossas implementações.

Nosso aplicativo grava arquivos em um local designado, fecha-os e grava um registro no banco de dados. Outra parte do aplicativo pega esses registros do banco de dados e lê o arquivo que foi gravado anteriormente.

Em alguns casos, o leitor está recebendo um "arquivo não encontrado" e ele falha. Reiniciando sem tocar em mais nada e encontra o arquivo corretamente e está tudo bem.

Acredito que descartei um problema com nosso aplicativo, pois o arquivo é definitivamente liberado / fechado antes que o registro do banco de dados seja criado.

Portanto, sou levado a acreditar que o sistema operacional ou o sistema de arquivos está atrasando a gravação do arquivo internamente para que ele não fique imediatamente disponível.

O sistema de arquivos em questão é o Windows 2003 SP2 DFS. Este é um cenário provável com este DFS? Em caso afirmativo, é possível transformá-lo em algum tipo de diretiva write-through / no caching para garantir que os arquivos sejam gravados imediatamente?

    

Answer 1

O DFS é Distributed File System, que é exatamente o que o nome diz: um compartilhamento de arquivo "virtual" distribuído e replicado em vários servidores. Toda vez que seu aplicativo grava nele, ele está realmente acessando uma de suas cópias em um dos servidores que fazem parte dele, e se outro aplicativo tentar ler os mesmos dados logo em seguida, ele pode muito bem estar acessando outro servidor, que não o fez. t receber os dados atualizados ainda.

Com o DFS, você nunca pode ter certeza absoluta de que os dados gravados nele estarão disponíveis em uma leitura subsequente: poderia haver sempre latência de replicação; você também não tem como dizer ao seu aplicativo para "conversar" com um servidor DFS específico: ele está livre para se conectar a qualquer um dos servidores que o executam.

Se você deseja que este aplicativo funcione em tempo real, você deve usar um compartilhamento de arquivo padrão, não um DFS.

    

Answer 2

Você está fazendo a suposição comum, mas incorreta, de que há uma noção universal de "depois" e que, se você fizer uma coisa "depois" de outra, estará garantido para ver os efeitos. Isto é simplesmente uma falsa noção, e nada que você possa fazer fará com que ela funcione do jeito que você espera.

A analogia seria enviar uma carta para alguém, receber um recibo de retorno, ligar para a pessoa no telefone e assumir que ela deve ter lido a carta.

Como você mencionou, as gravações atrasadas vão estragar tudo. Muitas outras coisas podem estragar tudo também. Tentar encontrar todas as formas possíveis para quebrar e consertar tudo é uma loucura.

Em vez disso, se você precisar fazer pedidos entre operações, use algo que seja especificamente garantido para fornecer o pedido específico de que você precisa. Como não há garantia de ordenação entre o sistema de arquivos e o banco de dados, isso não funcionará.

A maioria dos sistemas de arquivos fornece pedidos garantidos em relação a eles mesmos e suas próprias operações quando acessados através de processos executados na mesma instância do sistema operacional. Então, depois que o arquivo estiver corretamente configurado, você pode criar um arquivo 'trigger' no mesmo sistema de arquivos. Se o leitor visualizar o arquivo acionador, ele poderá saber que o arquivo de dados está completo e válido. Pode remover o arquivo de gatilho quando terminar.