[firebase-br] Travamento Otimista ou Pessimista
Francisco Thiago de Almeida
jeandeadlucky em yahoo.com.br
Qui Jan 13 10:53:02 -03 2005
O Cache que eu falo, não seria no próprio Firebird.. usando O Commit e
Rollback.. Seria localmente usando ClientDataSet.. Porque pelo pouco que
entendo de bancos, acho que isso você não vai encontrar em banco nenhum...
sempre vai dar DeadLock, pois você está querendo atualizar o mesmo registro
duas vezes.. o que é impossível..
Espero estar ajudando
Thiago
----- Original Message -----
From: "Marciano Bandeira" <marciano.bandeira em bol.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Thursday, January 13, 2005 10:35 AM
Subject: Re: [firebase-br] Travamento Otimista ou Pessimista
Obrigado pela atenção
É exatamente isso que eu fasso, esses DeadLock então tem que ser eu que
tenho que contornar o Firebird não tem esses recursos?
Desde ja agradeço
Marciano Bandeira
----- Original Message -----
From: "Francisco Thiago de Almeida" <jeandeadlucky em yahoo.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Thursday, January 13, 2005 10:06 AM
Subject: Re: [firebase-br] Travamento Otimista ou Pessimista
> Olha, eu não sei exatamente o seu problema ae.. mas considerando que uma
> venda só será efetuada no final da venda, acredito que você deveria
deixar
> estas opções em cache e só no final da venda atualizar estoque e tudo o
> mais.
> Assim você reduziria o tempo em que as transações ficariam abertas,
evitando
> os DeadLock
>
> É isso ae
>
> Espero ter ajudado
>
> Thiago
>
> ----- 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
> >
>
>
>
>
>
> ______________________________________________
> 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
______________________________________________
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