Uma forma de tratar esse tipo de problema poderia ser utilizar procedures e dentro das mesmas fazer o tratamento das exceptions de Deadlock. No caso, poderias retornar ao começo de tua procedure quando ocorrer a exception, contudo como entrou no tratamento da mesma, a outra função que estava travada acabou sendo liberada e provavelmente conseguiu prosseguir. Não sei se dessa forma seria suficiente para o que desejas, mas é uma forma de tratar problemas de deadlocks e que já utilizei mais de uma vez.
Espero que ajude, André. 2009/8/21 Mozart Hasse <[email protected]> > Leandro, > > > Sei que não é a resposta esperada, mas a verdade a vezes doí, deadlock é > > problema de lógica da aplicação. > > Essa regra tem exceção. > > > Você pode ter milhares de transações em > > paralelo e não ter deadlock, > > Teu sistema e tua modelagem precisam ser radicalmente simplórios para isso > acontecer. > > > Para resolver problemas deadlock não é necessário > > sacrificar paralelismo > > Depende do número de tabelas envolvidas nas suas transações e no número de > transações diferentes que você tem na sua aplicação. É fácil evitar > deadlocks se > todas as telas do seu sistema sempre gravam nas mesmas tabelas, porém este > caso > é trivial demais para servir para o mundo real. > > > e sim rever a lógica de aquisição de locks da aplicação. > > Como já disse, posso até rever a lógica e colocar alguns LOCKs estratégicos > para garantir > a inexistência de deadlocks, porém isso afetará sim, e muito, a capacidade > de paralelismo > do servidor. E afetará de forma tão significativa que compensa ter um > trabalho *enorme* > cuidando dos erros e problemas gerados pelos raros casos em que deadlocks > ocorrem > atualmente. > > > Uma dica simples é adquirir os locks nos objetos sempre na mesma ordem. > > Esta solução simplória é excelente como regra geral, porém insuficiente > para > todos os casos práticos. > > > Para defender o postgresql posso ter informar que por exemplo o bancos > > de dados bam-bam do mercado (Oracle) não tem comando similar a este e > > isto não é um problema. > > Problemas com deadlocks sempre podem ser mitigados superdimensionando o > servidor, como > é comum em instalações Oracle. Isto nem de longe quer dizer que o Oracle > também não se > beneficiaria com isso, nem que ele está livre das mazelas dos deadlocks, > especialmente para as > almas penadas que pensavam que podiam usar os bitmap indexes dele sem ter > problemas com > deadlocks, por mais bem feita e planejada que seja sua aplicação. Esta > "decisão técnica" não é > a primeira péssima idéia do Oracle nem de longe a única, e a última coisa > que o Postgres > precisa fazer como produto é imitar os erros dos seus concorrentes, > especialmente quando > existem benefícios concretos como desempenho e simplicidade de projeto. > > Para quem quer ser melhor que seus concorrentes, fica a solicitação de > inclusão dessa > funcionalidade. > > Mozart Hasse > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
