Pesquisa personalizada

Desenvolvimento Client/Server, Locks, transações e afins

Quando trabalhamos com bancos de dados em rede muitos dizem que estamos utilizando a arquitetura client/server. Porém a arquitetura client/server possui muitos principios que precisam ser respeitados. É comum, portanto, que programadores iniciantes coloquem bancos de dados em rede sem estarem realmente utilizando a arquitetura client/server.

Neste artigo vamos mostrar os principios desta arquitetura. Para começar devemos entender o que é um

Servidor de Banco de Dados

Para entendermos o que é um servidor de banco de dados vamos fazer uma comparação entre o Access e o SQL Server quando utilizados em rede. Digamos que exista uma tabela de clientes com 1.000.000 de clientes em cada um e precisemos localizar o "João".

Access : O access é um arquivo (.MDB) que fica localizado em um servidor. Sendo um arquivo, não realiza processamento. Assim sendo a aplicação client terá que ir ao servidor, abrir o arquivo e localizar o "João". A aplicação client estará realizando o processamento para localização do "João", portanto todos os 1.000.000 de registros precisarão trafegar pela rede até a máquina client para que está possa processa-los.

Consequentemente esta forma de trabalho sobrecarrega a rede e as máquinas dos usuários. Por esse trabalho ser baseado em arquivo o access não é considerado um "servidor de dados", alguns o chamam de um simples "bando de dados".

SQL Server : O SQL Server é um serviço trabalhando em um servidor. Um serviço é uma aplicação que não precisa ser iniciada pelo usuário, inicia-se automaticamente assim que o servidor é iniciado mesmo que não exista usuário algum logado.

A aplicação client não faz acesso a arquivo, até porquê ela não faz idéia de onde esteja localizado o arquivo de dados. A aplicação client acessa o serviço e este faz a busca pela informação desejada, no caso o "João". O serviço devolve o "João" pela rede para a aplicação client, desta forma existe um menor tráfego de rede e a máquina do usuário ficará bem menos sobrecarregada.

Além disso, com a centralização do processamento de busca no servidor este pode realizar dezenas de otimizações que tornarão a busca muito mais rápida.

Com esta comparação acredito que tenha ficado claro o que é um verdadeiro servidor de dados. Vamos agora ver o que são as

Regras de Negócio

Regras de negócio são regras relativas ao funcionamento da empresa. Por exemplo : Não poder vender se não houver produto no estoque, disparar uma compra quando o estoque atingir um valor mínimo, tudo isso são regras de negócio.

Não devemos confundir regras de negócio com regras de validação. Regras de validação são regras ligadas a campos tal como o nome não pode estar vazio, enfim, regras bem mais simples e que não envolvem acesso a múltiplas tabelas para serem implementadas.

As regras de validação são, em geral, implementadas no client. Desta forma evita-se tráfego desnecessário na rede, pois os dados já vão ao servidor validados. As regras de negócio, porém, não devem ser implementadas no client por vários motivos.

• Implementar regras de negócio no client implica que o client deveria acessar diversas tabelas, o que aumenta o tráfego de rede.
• Gera problemas com concorrência de dados. Quando o servidor é o responsável por reduzir o estoque fica mais fácil lidar com a concorrência de dados.

Servidores de dados oferecem como recursos as Stored Procedures e os Triggers, que permitem a implementação de regras de negócio no servidor. Stored Procedures são rotinas escritas em linguagem SQL que rodam no servidor e podem manipular os dados do servidor. A diferença dos Triggers para as procedures é que ao contrário das procedures os Triggers não podem ser chamados pelo client. Eles são disparados automaticamente pelo servidor em resposta a eventos ocorridos com uma tabela, tal como a inserção de um registro ou a deleção de um registro.

No exemplo do estoque, esta regra poderia ser implementada em um procedure ou em um trigger. Se for implementada em uma procedure tira-se o acesso direto do programador à tabela e obriga-se que ele chame a procedure para gravar uma venda. A procedure faz todas as checagens necessárias, podendo inclusive reduzir o estoque.

Sendo implementado em um trigger o trigger interceptaria a inserção de um registro, validando a venda e reduzindo o estoque automaticamente.

Veja algumas das vantagens da implementação das regras de negócio no servidor, além das 2 já mencionadas acima :

• É mais fácil mudar a regra de negócio sem necessidade de redistribuir toda a aplicação
• Procedures geram um aumento de performance
• É comum existirem várias aplicações acessando o mesmo servidor. Com as regras no servidor diminui-se a complexidade na construção de aplicações que acessarão esse servidor, tendo-se tanto uma economia quanto maior segurança contra falhas de programação.

Uma vantagem adicional, que merece destaque, são os recursos adicionais do servidor, que poucos programadores conhecem. Veja um exemplo com relação ao SQL Server :

• Tarefas no banco de dados podem ser agendadas
• O servidor pode agendar o envio de e-mail contendo o resultado de determinada query - um relatório agendado, por exemplo.
• Os agendamentos podem analisar valores nos modelos de dados, disparando alertas quando algo for atingido, um determinado montante de vendas, por exemplo. Avisos podem ser enviados por e-mail.
• A geração de HTML agendada ou sempre que ocorrer uma alteração de dados (trigger) é mais fácil do que a produção de aplicações ASP e melhor em performance, isso nas situações específicas em que pode ser aplicada.

Assim sendo, todo o modelo de dados e as regras de negócio são implementados no banco de dados utilizando-se linguagem SQL, enquanto que à aplicação resta acessar as procedures geradas no servidor. Se o programador que fará o trabalho no banco não é o mesmo que criará a aplicação então o programador que criará a aplicação nem ao menos saberá qual a estrutura do banco de dados, saberá apenas quais procedures chamar. Isso dará total liberdade ao administrador do banco para realizar otimizações no modelo de dados sem prejudicar o funcionamento da aplicação.

Por outro lado se um único programador for realizar todas essas tarefas observa-se ai o quão fundamental é para um bom desenvolvedor o conhecimento de linguagem SQL.

Transações

Imagine você as 3:00Am em um caixa eletrônico precisando tirar R$ 500,00 (a noite foi boa, hein?!) . Você aperta tudo, o caixa eletrônico faz o débito na sua conta mas na hora de emitir o recibo e soltar o dinheiro alguma coisa queima e ele pifa.

Esse é o típico problema em que observa-se a necessidade de uma transação. O caixa eletrônico não pode debitar da sua conta sem emitir o recibo e soltar o dinheiro e também não pode soltar o dinheiro sem fazer o débito na sua conta (bem que você gostaria, né?)

Neste caso as 3 tarefas devem ser agrupadas em uma transação. A transação garante que as 3 tarefas serão sempre concluidas em conjunto ou abortadas em conjunto, mas jamais uma delas será realizada sem que as demais também sejam.

Observe que a transação está diretamente relacionada com as regras de negócio, ela será normalmente utilizada para implementar tais regras. Justamente por isso as transações em geral estão no servidor. A aplicação client pode abrir uma transação, executar várias instruções e fechar, mas isso pode ser mais eficiente se estiver no servidor.

Inicialmente pode-se pensar que se a aplicação client envia um único update ou insert para o servidor isso não está em uma transação. Mas na verdade toda instrução de alteração de dados está em uma transação. Ocorre que quando o servidor recebe uma instrução isolada ele automaticamente a considera como uma transação de uma única linha.

Transações sempre envolvem alterações de dados. Não existe uma transação sem alteração de dados. Além disso a transação está diretamente ligada a problemas de concorrência de dados pois é a transação que gerencia a concorrência de dados, determinando quando os locks serão obtidos e dispensados.

Então nosso próximo passo é vermos como funciona a

Concorrência de dados

Uma pergunta muito comum entre programadores iniciantes é "Como lockar um registro ?". Normalmente tais programadores se surpreendem ao descobrirem que o sistema de locks de servidores de dados chega a ser bem mais complexo do que imaginam inicialmente ao ponto desta pergunta não ter resposta.

Vejamos o exemplo do SQL Server. O SQL Server tem 3 (tem mais, mas só precisamos mencionar esses agora) tipos de lock : Shared, update e exclusive. Todo programador se surpreende ao descobrir que uma aplicação client não pode solicitar o lock exclusive ao servidor.

Além disso o SQL Server utiliza um conceito de compatibilidade de locks - os locks possuem uma compatibilidade entre si, determinando quais locks podem ser obtidos simultaneamente sobre o mesmo registro. Isso mesmo : 2 usuários podem ter diferentes tipos de lock sobre o mesmo registro ao mesmo tempo.

O lock shared é compatível com ele mesmo (2 usuários podem ler registros ao mesmo tempo) e com o lock de update, mas não é compatível com o lock exclusive. O lock de update é compatível com o shared (podem haver pessoas lendo um registro mesmo após o registro ter sido solicitado para alteração), mas não é compatível com o lock de update (2 pessoas não podem pedir alterações simultaneamente) nem com o lock exclusive. O lock exclusive não é compatível com nada.

O lock shared é utilizado quando está sendo feita leitura nos dados. O lock de update é utilizado quando um registro é lido com intenção de atualização. O exclusive ocorre sempre que uma informação é atualizada. Observe que existe uma evolução entre os locks : o shared se transforma em de update e o update em exclusive.

O lock de update não pode se transformar em exclusive enquanto houverem locks shared no registro, devido a incompatibilidade do exclusive com shared. O shared não se transforma em update se já houver um update no registro.

A essa altura você deve estar imaginando como isso funcionará na interface. O lock shared ocorre sempre que é feita uma leitura. Mas as leituras são feitas apenas quando a tela é aberta. Após a abertura da tela já foi criado um cursor (já assistiu nossa palestra sobre cursores?) que pode estar no client ou no server, mas de qualquer forma a navegação do usuário não gera lock algum no banco de dados.

Quando o usuário fizer uma alteração de dados a aplicação client estará enviando uma instrução para o servidor realizar a alteração. Neste momento será obtido um lock de update que de imediato se tranformará em lock exclusive e será retirado quando a alteração for concluida.

E o que acontece se houverem locks shared, de update ou exclusive ?

Como vimos, a obtenção do lock shared é momentânea. A do lock de update e exclusive também. Então se os locks conflitarem o servidor simplesmente irá esperar os locks serem liberados para continuar a alteração. Normalmente é um processo muito rápido.

E o que acontece se duas pessoas tentarem alterar dados simultaneamente ?

Alteração precisamente simultânea não ocorrerá : Um deles obterá o lock primeiro. Pelo que vimos até agora o usuário que fizer a alteração por último sobrescreverá os dados do primeiro usuário, gerando uma perda de dados (ninguém analisou para ver se os dados poderiam ser sobrescritos).

Para resolver esse problema entra justamente o papel da aplicação client : O ADO possui um gerenciamento para isso - sempre que o ADO faz uma gravação de dados ele procurar por todos os dados do registro. Assim sendo se algum outro usuário alterou o registro primeiro o ADO não encontrará o registro e retornará um erro para a aplicação client.

Desta forma conclui-se que a aplicação client sempre será avisada de um problema de concorrência de dados e cabe ao programador decidir o que fará entre diversas opções :

• Dizer ao usuário que ele perdeu tudo
• Forçar a gravação por cima sem dizer nada
• Avisar ao usuário que outra pessoa gravou primeiro, deixa-lo comparar os registros e decidir o que fazer.

Desta forma chega-se a conclusão de que a forma mais simples de gerenciar os locks é NÃO FAZER LOCKS. Além de mais simples mostra-se a melhor por vários motivos :

• Locks só existem dentro de transações. Para lockar um registro seria necessário estar com uma transação aberta durante a edição de dados.
• Locks geram o chamado "Efeito cafezinho", já comprovado em teses de mestrado. Sempre que um lock é aplicado o usuário sente uma irresistível necessidade de sair para tomar um cafezinho, deixando o(s) registro(s) lockados. Conhece-se histórias de usuários que lockaram toda uma tabela, desligaram o vídeo e foram para casa.
• Gera um ambiente complexo de ser gerenciado com poucas vantagens em relação a abordagem de não fazer locks

Em treinamentos de Visual Basic e SQL Server da Búfalo Informática esse assunto é analisado em muitos detalhes.

Vamos então a outra grande dúvida dos programadores, como melhorar a

Performance

Outras perguntas constantes entre programadores são "Meu banco tá travando... tá dando timeout, como resolvo ? " e "Como faço para usar índices através da aplicação ?"

É muito frequente que problemas de performance sejam confundidos com problemas de locks. Quase sempre quando temos um timeout na conexão o problema é de locks, não de performance.

Outra questão que normalmente confunde os programadores é o fato de que o servidor já tem o seu gerenciamento com relação a performance de querys, a aplicação não faz nada a esse respeito. Quem gerencia índices é o DBA. O servidor é inteligente o suficiente para escolher o melhor índice a ser usado para cada query.

O papel do programador, no que se refere a performance é apenas de passar para o DBA as querys que estão sendo realizadas no banco de dados para que este possa planejar sua otimização ou recomendar mudanças nestas querys. Isso quando muito, pois se as regras de negócio estiverem implementadas em procedures no servidor, como recomendamos acima, nem com a montagem de querys o programador irá se envolver e o DBA terá total liberdade para fazer alterações no banco para melhoria de performance.

Conclusão

Como vemos, o atual ambiente de desenvolvimento envolve uma série de conceitos muito mais complexos que os existentes na época do Clipper/Pascal, exigindo uma dedicação muito maior dos desenvolvedores para se manterem atualizados e dificultando o autodidatismo. Deve-se ressaltar ainda que todo este ambiente aqui exposto (client/server), é considerado ultrapassado, sendo recomendada a substituição pelo ambiente de aplicações distribuidas (Windows DNA no conceito Microsoft), que utiliza todos esses conceitos, ampliando-os para o ambiente distribuido.

Em nossa área de tecnologia temos artigos explicando o ambiente Windows DNA.

Dennes Torres
MCSD,MCSE,MCDBA

>>Após esse artigo, faça um Treinamento de Técnicas de Desenvolvimento (Visual Basic 6)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

• Visite nossa área de artigos técnicos
• Conheça nossas dicas técnicas (mais de 300 dicas)
• Conheça nosso fórum de discussões
• Conheça nossa área de download com muitos componentes e códigos úteis
• Conheça nosso treinamento de lógica de programação on-line
• Conheça nossa prova de certificação em VB (oferecemos certificado aos aprovados)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::