[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