Os servidores de arquivos de rede têm muitos clientes para cuidar. Se acontecer de dois ou mais clientes acidentalmente deciderem acessar o mesmo arquivo mais ou menos ao mesmo tempo, podem ocorrer problemas. Considere o cenário a seguir. Dois clientes abrem o mesmo arquivo para escrita. Então, cada um deles transmite simultaneamente um pedido para substituir o primeiro registro do arquivo. O último pedido a ser executado vence, e sobrescreve o outro. É difícil elaborar aplicações confiáveis sob essas condições.
Uma solução amplamente utilizada nas implementações é permitir aos clientes bloquearem arquivos antes de os utilizarem. São usadas duas espécies de bloqueios:
- os bloqueios compartilhados que são usados geralmente para leitura;
- os bloqueios exclusivos que são normalmente utilizados para escrita.
Quando um cliente solicita um bloqueio compartilhado sobre um arquivo, em geral no momento em que o arquivo é aberto, o bloqueio só estará garantido se o arquivo for desbloqueado ou tiver outros bloqueios compartilhados sobre ele. Se houver um bloqueio exclusivo sobre o arquivo, o pedido na abertura não pode ser garantido. Os bloqueios exclusivos só são garantidos em arquivos desbloqueados.
Quando lê um arquivo, um cliente em geral não faz idéia da existência de outros leitores, mas quer o bloqueio compartilhado simplesmente para evitar que o arquivo seja alterado enquanto estiver ocupado. Contudo, quando escreve em um arquivo, o cliente precisa estar seguro de que nenhum outro leitor ou escritor está em atividade.
Quando um arquivo está em uso intenso por muitos clientes, principalmente para leitura mas ocasionalmente para escrita, pode ocorrer um problema se pedidos não garantidos forem simplesmente rejeitados. Com o tempo, alguns leitores terminam, mas outros entram, e assim sempre existem leitores ativos e nenhum escritor pode jamais começar. Como uma alternativa para rejeição imediata dos pedidos de bloqueios exclusivos, o servidor poderia enfileirá-los, e também enfileirar quaisquer novos pedidos de bloqueios compartilhados. Quando os leitores atuais finalmente terminarem, o primeiro escritor na fila recebe sua oportunidade. Depois que ele termina, o servidor tem de tomar uma posição politica sobre a permissão a outros escritores ou leitores para entrarem em atividade a seguir.
O bloqueio apresenta diversos problemas incômodos. Em primeiro lugar, se um cliente precisar acessar vários arquivos, como é o caso comum na transferência de dinheiro em aplicações bancárias, há um potencial para impasses. Se o cliente 1 tiver um bloqueio no arquivo A e o cliente 2 tiver um bloqueio no arquivo B e cada um está tentando alcançar o outro arquivo, nenhum deles jamais terá sucesso. Algumas vezes são possíveis soluções ad hoc, como fazer com que todos os clientes bloqueiem arquivos em ordem alfabética, dessa forma evitando ciclos mas, em geral, evitar o impasse é tarefa para os clientes, não para o servidor de arquivos.
Outro problema relacionado ao bloqueio é o que acontece se um cliente que detém alguns bloqueios tem uma pane. A menos que algo seja feito, os arquivos bloqueados ficarão nessa condição para sempre. Se o servidor não estiver informado sobre quedas nos clientes, a única coisa que ele pode fazer é adotar uma política de interromper bloqueios automaticamente em arquivos que não sejam acessados depois de algum intervalo de tempo especificado. Contudo, se um cliente for excessivamente lento, ele pode descobrir que alguns dos seus bloqueios foram interrompidos à sua revelia através de uma atualização complexa de múltiplos arquivos, levando ao caos.
Como alternativa para fazer com que os clientes definam bloqueios individuais, alguns servidores de arquivos suportam ações atômicas, freqüentemente chamadas transações no contexto dos servidores de arquivos. Quando esse recurso está disponível, um cliente pode dizer ao servidor para iniciar uma transação, seguida por qualquer número de aberturas e operações de arquivos e encerrada por um comando que finaliza a transação. Cabe ao servidor conduzir todos os pedidos de uma forma atômica, sem inferência de outros pedidos de clientes. Se o cliente decidir abortar a transação ou se ele se interromper, ou alguma outra coisa sair errada, todos os arquivos são restaurados ao estado em que se encontravam antes de a transação se iniciar.
As transações podem ser implementadas fazendo-se o servidor construir uma cópia de cada arquivo que é aberto para escrita. As alterações feitas por escritas subseqüentes são realizadas na cópia, e não original. Se a transação se completar com sucesso, as cópias substituem os originais. Se múltiplos servidores estiverem envolvidos, podem ser usadas as técnicas do CCR (Compromisso, Concorrência e Recuperação).
