[firebase-br] Deadlock on execute procedure

[Carlos H. Cantu]

CM> WAIT apenas faz esperar pela decisão da outra transação, mas se a outra
CM> transação der commit ao invés de rollback, vai dar update conflict do mesmo
CM> jeito.

Quando respondi eu não tinha me atentado que você estava usando
read_committed e não snapshot, então realmente não dá deadlock quando
a outra transação commita.

Pro Firebird tanto faz a transação concorrente ter sido iniciada na
mesma aplicação ou em outra. Na sua aplicação de exemplo você está
usando IBX e threads pra demonstrar o problema. Eu não conheço o IBX, não
sei exatamente o que ele pode estar fazendo "por debaixo dos panos",
mas deve ter alguma falha na sua lógica ou implementação, ou talvez no
próprio IBX.

PS: Vc inicia a thread no OnCreate do mainform, ou seja, antes do
application.run, acho que isso tb pode estar contribuindo com o
"comportamento" obtido.

Sugiro que vc use a TraceAPI do Firebird para logar tudo que está
acontecendo entre o seu exemplo e o Firebird, pra ver exatamente o que
está sendo enviado pra ele e, importante, saber a ordem que as
instruções estão chegando. Acho que isso vai ajudar vc a desvendar o
mistério.

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 4 - www.firebase.com.br/guiafb4.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

CM> Carlos,
CM> Isto não é verdade. Fiz vários testes e com o parâmetros read_committed e
CM> no_rec_version (wait desta forma está implícito), a 2ª transação aguarda
CM> sempre pelo commit da 2ª e nunca dá qualquer erro, tenha a 1ª feito Commit
CM> ou Rollback. Testei e posso enviar um testcase se for necessário.

CM> Apenas falha, como já disse, se as transações concorrentes forem dentro da
CM> mesma instancia, isto é:
CM> t1.starttrasaction;
CM> update some_table set campo = '12345' where chave = 1;

CM> t2.starttransaction;
CM> update some_table set campo = '12345' where chave = 1; // Aqui vai dar
CM> Deadlock

CM> se a situação for esta:
CM> t1.starttrasaction;
CM> update some_table set campo = '12345' where chave = 1;
CM> showessage('Stop');

CM> e a seguir executar outra instancia da aplicação, este 2ª instancia vai
CM> aguardar indefinidamente até que a 1ª faça o Commit, sem dar qualquer erro.

CM> Ou é defeito ou é mesmo assim que as transações no Firebird se comportam,
CM> não sei, mas é o que acontece.



CM> -----Mensagem original-----
CM> De: lista <lista-bounces em firebase.com.br> Em Nome De Carlos H. Cantu via
CM> lista
CM> Enviada: 28 de outubro de 2021 00:22
CM> Para: FireBase <lista em firebase.com.br>
CM> Cc: Carlos H. Cantu <listas em warmboot.com.br>
CM> Assunto: Re: [firebase-br] Deadlock on execute procedure

CM> WAIT apenas faz esperar pela decisão da outra transação, mas se a outra
CM> transação der commit ao invés de rollback, vai dar update conflict do mesmo
CM> jeito.

CM> Sugiro que leia o artigo que te mandei no email anterior.

CM> []s
CM> Carlos H. Cantu
CM> eBook Guia de Migração para o FB 4 - www.firebase.com.br/guiafb4.php
CM> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

CMvl>> Não estou a usar datawares.  
CMvl>> Estou usando Delphi a acessando as bds do firebird através das
CM> componentes IBX.

CMvl>> Fiz um teste e se usar na transação os parâmetros:  
CMvl>> Read_committed
CMvl>> No_rec_version

CMvl>> E sendo que assim o parâmetro wait está implícito (testei e está 
CMvl>> se facto), havendo um update concorrente com outra transação, esta 
CMvl>> 2.ªtransacao deveria esperar que a 1.a faça o commit, mas não, 
CMvl>> está a dar erro.

CMvl>> Será que isto apenas acontece se estivermos a falar de instâncias 
CMvl>> diferentes, ou seja, o mesmo programa chamado duas vezes?!!!
CMvl>> Será que o problema é, estando eu com duas transações iniciaras na 
CMvl>> mesma instância do programa, a 2.ª quando apanha um update 
CMvl>> concorrente, gera o erro ignorando o parâmetro wait?!!!

CMvl>> --
CMvl>> Carlos Matos


CMvl>> Ligado 27 de outubro de 2021 às 21:58:41, Gladiston Santana via 
CMvl>> lista (lista em firebase.com.br(mailto:lista em firebase.com.br)) escreveu:

>>> se estiver usando datawares (dbedit, dbcombobox, dbmemo, ....) e 
>>> depois dispara uma stored talvez seu problema esteja num 
>>> autocommit=true do firedac, isto é, não é tudo na mesma transação, 
>>> ele tá abrindo e fechando e em algum momento que disparar a stored 
>>> vai encontrar seu trabalho em edição e causando o lock. Mais ainda se 
>>> houver triggers encolvidas. Dá uma olhada nisso. Procedimentos 
>>> longos, eu gosto de fazer as transações manualmente ou pô-los em 
>>> execute block, mesmo que chamasse uma SP lá dentro apenas para garantir
CM> tudo no mesmo lugar.
>>>  
>>> Em qua., 27 de out. de 2021 às 11:13, Carlos Matos via lista < 
>>> lista em firebase.com.br> escreveu:
>>>  
>>> > Estou tendo um problema há vários meses.
>>> >  
>>> > Estou a usar o Firebird 4 e tenho uma unit onde faço várias 
>>> > operações, select, update, insert e no final estou a executar um 
>>> > procedimento, ou seja, um Stored Procedure do Firebird.
>>> >  
>>> > Tudo isto está na mesma transação.
>>> >  
>>> >  
>>> ______________________________________________
>>> 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://www.firebase.com.br/pesquisa_lista.html
CMvl>> ______________________________________________
CMvl>> FireBase-BR (www.firebase.com.br) - Hospedado em 
CMvl>> www.locador.com.br Para saber como gerenciar/excluir seu cadastro na
CM> lista, use:
CMvl>> http://www.firebase.com.br/fb/artigo.php?id=1107
CMvl>> Para consultar mensagens antigas:
CMvl>> http://www.firebase.com.br/pesquisa_lista.html


CM> ______________________________________________
CM> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br Para
CM> saber como gerenciar/excluir seu cadastro na lista, use:
CM> http://www.firebase.com.br/fb/artigo.php?id=1107
CM> Para consultar mensagens antigas:
CM> http://www.firebase.com.br/pesquisa_lista.html