[firebase-br] Travamento Otimista ou Pessimista
Marciano Bandeira
marciano.bandeira em bol.com.br
Qui Jan 13 10:11:03 -03 2005
Obrigado pela resposta.
Nas vendas eu gravo tudo em tabelas temporárias e na hora de finalizar é
feita a baixa de estoque...
... Então quer dizer que não existe o travamento otimista de registro?
nisso é igual ao piradox, travamento pessimista?
// Desculpem a pergunta Off
Isso tbm ocorre em outros bancos de dados tbm? ex: SqlServer
Obrigado pela atenção
Marciano Bandeira
----- Original Message -----
From: "Fabiano Arndt" <fabianoallex em hotmail.com>
To: <lista em firebase.com.br>
Sent: Thursday, January 13, 2005 9:45 AM
Subject: RE: [firebase-br] Travamento Otimista ou Pessimista
> E aí Marciano,
>
> Seguinte, meus comentários serão mais teóricos, não posso garantir que o
> firebird faça exatamente dessa forma:
>
> vc tem duas transações, T1 e T2
>
> 1 - T1 inicia a transação
> 2 - T1 inclui um item (atualiza estoque), T2 inicia a transacao
> 3 - T1 inclui um item (atualiza estoque), T2 inclui um item (tenta
atualizar
> estoque - ERRO!!!)
> 4 - T1 comita
>
> na linha 2 vc inclui um item e automaticamente atualizou o estoque, ao
fazer
> isso vc bloqueo (lock) o registro onde está o valor do estoque (isso
> acontece exatamente pra evitar dados incossistentes), é como se vc
falase:
> "o registro é meu e ninguém mexe", outras transações poderao modificar o
> valor apenas quando a transação que deu lock no registro comitar o dar
um
> rollback, na linha 2 ainda vc inicia outra transação (T2).
>
> na linha 3 T1 inclui outro item e atualiza o estoque novamente, e T2
também
> (de metido) tenta incluir um item e tenta atualizar o estoque, mas aí
como
> T1 ainda está com o registro bloqueado ele fala: "Cara, o registro é
meu,
> sai fora" e aí retorna o erro......,
>
> na linha 4 T1 comita e desbloqueia o registro, ai qualquer um pode mexer
no
> registro do estoque.
>
> existe (ou deveria existir) uma forma de ao invés de dar um erro na
linha 3,
> T2 ficar aguradando T1 comitar, e após então ele também comitar, mas
isso
> faria com que a tela de quem disparou o T2 ficasse congelada para o
usuário
> até que o usuário que disparou T1 comitase, o que também não é legal,
>
> ficaria +- assim
>
> 1 - T1 inicia a transação
> 2 - T1 inclui um item (atualiza estoque), T2 inicia a transacao
> 3 - T1 inclui um item (atualiza estoque), T2 inclui um item (tenta
atualizar
> estoque - aguarda)
> 4 - T1 inclui um item (atualiza estoque), T2 inclui um item (tenta
atualizar
> estoque - aguarda)
> 4 - T1 comita, T2 comita
>
> mas aí vc poderia fazer apenas uma venda por vez, ou seja todos os
terminais
> ficariam parados ate que o terminal que está fazendo a venda terminasse
a
> venda.
>
> o ideal então seria vc fazer assim:
>
> 1 - T1 inicia a transação
> 2 - T1 inclui um item (atualiza estoque)
> 3 - T1 comita
> 4 - T1 inicia a transação
> 5 - T1 inclui um item (atualiza estoque)
> 3 - T1 comita
>
> ou seja após incluir cada item vc comita e libera o registro, assim se
por
> um acaso alguém tentar atualizar o estoque e o registro tiver bloqueado,
a
> transação não precisará esperar muito tempo e no final seus dados
estarao
> consistentes,
>
> isso pode funcionar com trigger ou sem trigger, o que importa é o
contexto
> da transação, seja numa trigger, seja no programa ou onde for.... ah
> lembrando que uma trigger sempre está no mesmo contexto da transação que
a
> disparou.
>
> se alguém com maiores conhecimento ver que falei alguma besteira, favor
me
> corrija,
>
> Espero ter ajudado, qualquer duvida é só falar,
>
> []'s
> Fabiano.
>
>
> >From: "Marciano Bandeira" <marciano.bandeira em bol.com.br>
> >Reply-To: FireBase <lista em firebase.com.br>
> >To: "FireBase" <Lista em firebase.com.br>
> >Subject: [firebase-br] Travamento Otimista ou Pessimista
> >Date: Wed, 12 Jan 2005 16:41:52 -0200
> >
> > Boa tarde a todos
> >
> > Uma coisa está me esquentando a cabeça a algum tempo, estou
> >desenvolvendo um sistema de vendas com banco de dados firebird, que
rodará
> >em rede, até aí tudo blzinha
> > Mais digamos que o produto 1 da tabela de produtos tenha o estoque
50,
> >aí o Terminal_1 vai e vende 10 unidades do Produto 1, mais antes de
comitar
> >(pois estará gravando outos items), o Terminal_2 vai e vende 5 unidades
do
> >produto 1 e Comita a transação, aí o estoque do produto 1 cai para 45,
aí o
> >Terminal_1 Comita a transação dele, como ficará o estoque, ele baixará
para
> >35 que seria o correto, ou baixará para 40 que era o que seria correto
> >quando ele fez a gravação?
> > OBS..: As baixas de estoque estou fazendo dentro de Triggers.
> > OBS2: Tentei fazer o teste pelo IbExpert e ao tentar gravar o Item
no
> >Segundo terminal antes de comitar o primeiro apareceu a seguinte
mensagem:
> >
> > "Error Message:
> > ----------------------------------------
> > Unsuccessful execution caused by system error that does not preclude
> >successful execution of subsequent statements.
> > lock conflict on no wait transaction.
> > deadlock.
> > update conflicts with concurrent update."
> >
> > Outra pergunda, se o Firebird/Interbase faz travamento otimista de
> >registro porquê dessa mensagem?
> >
> > Fica as duas perguntas no ar
> > Agradeço a todos que poderem me ajudar
> > Marciano Bandeira
> > msn: cbndesenvolvimento em hotmail.com
> > skype: marcianobandeira
> >
> >
> >______________________________________________
> >FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >Para editar sua configuração na lista, use o endereço
> >http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>
> _________________________________________________________________
> MSN Messenger: converse online com seus amigos .
> http://messenger.msn.com.br
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Mais detalhes sobre a lista de discussão lista