[firebase-br] Multi-Usuário + Tabela temporária

Eduardo Pelizzari de Andrade eduardoandrade em persoft.com.br
Qua Dez 17 17:50:25 -03 2008


Renan,

Se eu estiver ensinando o "pai nosso" ao "vigário", me desculpe, mas 
estou com a impressão que você está lidando com um sistema legado, que 
foi migrado para a arquitetura cliente/servidor.

A maneira como um sistema cliente/servidor trata a concorrência, em 
geral é diferente de um sistema que não usa banco de dados 
cliente/servidor, como access, paradox, dbf etc. Nestes sistemas, 
geralmente você tem um número menor de usuários, que em geral estão 
fisicamente próximos e a solução que se dá para a concorrência é quando 
o primeiro usuário edita o registro, ele fica travado, quando um segundo 
usuário vai tentar editar o mesmo registro, recebe uma mensagem que não 
pode realizar a edição daquele registro. Ai ele levanta a cabeça e dá um 
berro "alguém ai está alterando o cadastro do cliente XYZ", quando 
ninguém na sala está editando, ele passa a mão no telefone e toca em 2, 
3 ramais que estão 1 andar abaixo e 1 andar acima acima de onde ele está 
e se ainda assim ele não acha quem está alterando o registro, ele liga 
para o "cara da informática", pentelha ele bem, ai ele faz o mesmo 
procedimento, toca uns ramais e se não resolve, sai andando pela 
empresa, até achar um micro de um infeliz que foi almoçar e deixou a 
tela de edição no meio da edição do registro, ai ele da escape, sai da 
tela e problema resolvido.

Os sistemas cliente/servidor são projetados para ter alto poder de 
escalabilidade, ou seja, você pode pendurar usuário a dar com pau e 
ainda assim ele tem que funcionar bem. Então imagina a situação acima e 
sistema que roda em filiais no brasil todo e milhares de usuário, para 
achar o infeliz vai dar trabalho, além disso, travar registro requer 
recurso no servidor, não dá para garantir a escalabilidade, consumindo 
estes recursos, por isso a concorrência é pensada de outra foram.

Salvo exceções, a concorrência vai ser tratada no momento de salvar o 
registro e ai existem três possibilidades:

1. Super otimista, onde se dois sujeitos abrem o cadastro de um cliente, 
e alteram o CNPJ, o último que salvou sobrepõe o dado. Nesta 
possibilidade o sistema irá lançar um update para o servidor, informando 
o que deve ser alterado e identificando a chave primaria do registro.

2. Na segunda possibilidade Se dois usuário abrem o cadastro de reservas 
de um vôo, o que reservou a poltrona primeiro vai salvar os dados (quem 
reservou primeiro, foi o primeiro que clicou no botão salvar e não o 
primeiro que iniciou a reserva), quando o segundo tentar reservar o 
sistema irá dar a mensagem que a aquela poltrona já foi reservada. Neste 
caso o update vai testar se o o valor do campo, ainda está igual ao 
valor quando o registro começou a ser alterado, ou seja, quando o 
usuário iniciou a reserva, o campo que correspondia ao status da 
poltrona do avião, veio como "LIVRE", quando ele tentou aplicar a 
alteração no banco de dados e passar para "OCUPADO", ele vai testar se o 
valor dela ainda é "LIVRE", caso contrário a exceção será levantada pelo 
banco de dados. Se um outro dado do mesmo registro foi alterado, o banco 
de dados não irá levantar exceção. Se este sistema implementasse um 
campo representando cada poltrona do avião, cada usuário poderia estar 
reservando uma poltrona diferente sem problemas para os demais usuários, 
apenas para aqueles que tentarem reservar a mesma poltrona quase 
simultanemente.

3. O terceiro é o pessimista,  uma situação onde será verificado se 
algum campo durante a edição do registro foi alterado e se qualquer 
campo do registro foi alterado a exceção é levantada e não se deixa o 
segundo usuário alterar o registro.

Existe a possibilidade de literalmente travar um registro dando um 
select com with lock, mas este recurso, quando usado, deve travar o 
registro e em seguida liberar, não é recomendável deixar o registro 
travado enquanto o usuário esta fazendo uma edição do registro, como se 
faz em sistemas que rodam local.

Os componentes de acesso a banco de dados, na verdade sempre vão estar 
disparando inserts, updates e deletes para o banco de dados. Todos os 
componentes do delphi que eu conheço, você pode configurar qual das três 
possibilidades será usado para aquela consulta. Se você usa o 
tclientdataset, você pode alterar a propriedade UpdateMode, do 
TProviderdataset e conseguir o tratamento de concorrência que você quiser.

Eduardo Pelizzari de Andrade
Persoft Softwares Aplicativos




Construção Construção escreveu:
> Olá Eduardo... Boa Tarde...
> Primeiramente, muito obrigado por responder a minha pergunta...
>
> Quanto a sua primeira dúvida: Quando digo que o sistema se "perde
> inteirinho" acontece que as vezes ele não consegue alterar o registro devido
> ele estar em edição em dois pontos dando mensagem de erro e as vezes ele
> altera nos dois pontos.
>
> Imagino fazer o controle da seguinte maneira: "Quando o usuário editar o
> registro eu iria gravar este registro na tabela temporária, ai se outro
> usuário selecionar este registro para alteração eu não iria deixar pois o
> mesmo esta gravado na tabela temporária". Lembrando esta tabela temporária
> deve ser do tipo GTT pois se não for não consigo ter certeza que o registro
> existente nesta tabela temporária está realmente em edição, devido ao
> processo poder ter sido abandonado por ctrl+alt+del ou queda de energia por
> exemplo.
>
>
>
> 2008/12/17 Eduardo Pelizzari de Andrade <eduardoandrade em persoft.com.br>
>
>   
>> Desculpe Renan, mas não entendi o seu problema.
>>
>> Até onde comprreendi, você está com problema de concorrência. Você diz que
>> o sistema "se perde inteirinho", imagino que o sistema levante uma exceção e
>> o segundo usuário não consegue alterar o registro, é isto?
>>
>> Ai você fala que todos usuários conectam-se com o SYSDBA. Isto não estaria
>> gerando o problema de concorrência, já que o controle é feito por conexão e
>> não por usuário.
>>
>> Ai você fala de tabelas temporárias, como você imagina que tabelas
>> temporárias resolveriam seu problema de concorrência?
>>
>>
>> Eduardo Pelizzari de Andrade
>> Persoft Softwares Aplicativos
>>
>>
>>
>>
>> Construção Construção escreveu:
>>
>>     
>>> Olá pessoal...
>>> Tenho um sério problema com multi-usuários em meu sistema, onde o sistema
>>> se
>>> perde em situações em que dois usuários diferentes em micros diferentes
>>> alterando o mesmo registro o sistema se perde inteirinho.
>>>
>>> Detalhes: Embora no sistema tenho vários usuários, todos são amarrados ao
>>> SYSDBA (devido a arquitetura montada na época do software construído, sei
>>> que isso é totalmente inseguro, mais devido a outras questões isso é
>>> inviável.)
>>>
>>> A solução ideal para meu problema inicial (multi-usuário) seria algo no
>>> banco de dados. Estive pesquisando e o que é muito bacana é a utilização
>>> de
>>> CTTs (tabelas temporárias) que ficam amarradas a conexão ai eu tenho
>>> certeza
>>> que aquele usuário esta utilizando o sistema naquele momento. Porém estes
>>> registros ficam visíveis apenas para a conexão.
>>>
>>> Minha dúvida é: Existe alguma forma de eu consultar TODOS os registros de
>>> uma tabela temporária? Vocês conhecem uma solução parecida com essa para o
>>> caso?
>>>
>>> Grato,
>>>
>>> T+
>>>
>>> Renan...
>>> ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>>> http://www.firebase.com.br/fb/artigo.php?id=1107
>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database:
>>> 270.9.18/1851 - Release Date: 16/12/2008 08:53
>>>
>>>
>>>
>>>       
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>>     
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.18/1851 - Release Date: 16/12/2008 08:53
>
>   




Mais detalhes sobre a lista de discussão lista