Introdução

Nos dias de hoje a maior parte dos projetos são multiuso e aplicações client/server, onde diversos usuários acessam e alteram os dados ao mesmo tempo. Com aumento das aplicações baseadas em browser, alguns problemas podem ser diagnosticados, um deles é a concorrência de dados.

Descrição do problema

O que é concorrência de dados? Bem, vamos imaginar um cenário hipotético para ilustrar a explicação. Imagine uma aplicação que possui um cadastro de clientes, este cadastro de clientes possui uma tabela nomeada cad_cliente e composta dos campos: codcliente, nomecliente. Onde codcliente é um integer e a primary key da nossa tabela e nomecliente é um varchar(20).

Agora imaginemos que o cliente do nosso banco de dados possui duas secretárias que atendem a todo pais e cadastram clientes a todo tempo. A secretária “A” abre um evento de inserção na tabela de cad_cliente ao mesmo tempo em que a secretária “B”, supondo que ambas fossem salvar ao mesmo tempo os registros, ou que por uma questão de velocidade de hardware as informações de gravação chegassem ao SGBD ao mesmo tempo, como seria definido o campo codcliente? Ok, poderiamos utilizar campos identity (campos auto-incrementáveis como os do MS-Access), porém não é minha intenção aqui discutir qual a melhor prática até porque isso vai depender do projeto, da estrutura e do ambiente. Pode ser uma ótima sugestão para um próximo artigo.

Solução proposta

Uma boa solução é criar uma tabela auxiliar (por exemplo, NumeroSequencial) que conterá o próximo número seqüencial para cada chave de cada tabela. Para cada registro inserido em uma tabela, você necessitará obter um valor da tabela NumeroSequencial e incrementar o número. Este valor deverá ser usado em um (ID) identificador único de registro a ser inserido.

O uso de sequence é uma prática muito comum principalmente em bancos como postgressql, ORACLE e outros, os quais possuem funções especificas para tratamento de seqüenciais. No caso do postgressql o comando Create Sequence cria um gerador de números seqüenciais, que envolve a criação e a inicialização de uma nova tabela com uma única linha.

Esta técnica é um caminho para implementar controle de concorrência de chaves quando não é possível utilizar campos identity. Técnica que também poderá causar problemas de transação, porque irá criar processos de read, lock e update em valores chaves. Teremos que fazer um controle de lock do registro para resolver esses problemas e não criar um lock da página de dados (o que não era possível em versões antigas do SQL Server, por isso muitos analistas afirmam que não é possível fazer controle de chaves concorrentes no SQL Server).

Solucionando o problema

Resolveremos esse problema por meios mecânicos aumentando o número de registros para preencher o tamanho de uma página de dados. Criando campos “dstmp” no formato char que será usado para adicionar o tamanho necessário aos registros até preencher o equivalente a uma página de dados.

Página de dados é a menor área de armazenamento de dados do SQL Server, e preenchendo ela, estaremos provocando o lock (quando for o caso) somente de uma linha, no caso a página de dados que foi ocupada por valores NULL.

No SQL Server 2000 e SQL Server 7.0, isso não é necessário já que nessas versões automaticamente o lock pertence a um registro e não a uma página de dados. (Lembrando que uma página de dados pode conter mais de um registro). Entretanto, o processo ainda pode competir para read, lock e update um valor chave no mesmo registro. Isto pode conduzir para um deadlock. A procedure que segue é usada para obter um identificador para da tabela NumeroSequencial.

Vamos voltar a nossa hipótese, nós temos dois processos no servidor e os dois necessitam inserir um registro em uma cad_cliente. Um processo lê o registro da tabela NumeroSequencial. Em seguida o outro processo também ira ler um registro da tabela NumeroSequencial. O primeiro processo assumira o mesmo Id do segundo já que ambos estão lendo a tabela ao mesmo tempo. Por isso cada um terá que ter um lock de registro, permitindo a os outros processos somente pegar o Id quando uma atualização estiver concluída. Esta situação é chamada de deadlock.

O SQL Server tem um mecanismo que ira matar um dos processos para que um possa continuar. Isso se faz necessário em uma aplicação client/server para evitar a perda de dados. O melhor caminho para tratar um deadlock é utilizar um hint na clausula From que segue no select forçando o SQL Server a criar um lock na clausula update e instantaneamente evitando o compartilhamento do registro. Um lock irá prevenir que outro processo venha a ler e criar locks até que o registro de origem seja completado.

O segundo processo irá esperar o primeiro processo ser concluído, segue a procedure com o tratamento de lock.

Conclusão

Neste artigo procuro mostar uma solução competente para resolver um problema grave de concorrência de dados usando o MS SQL Server, como eu disse no inicio do artigo não é meu propósito ficar discutindo se essa é a melhor ou pior técnica. Mas existem outras soluções, por exemplo: utilizar campos identity (campos auto-incrementáveis), fazer o controle de campos IDs através da aplicação e etc.. A escolha deve ser por conta do DBA ou AD do projeto, afinal cada caso é um caso e cada aplicação tem suas particularidades.

Web site: www.crespi.pro.br

email: rodrigo@crespi.pro.br