Chiappa, gosto muito do nível de detalhes que vc responde, colocando bons
exemplos e sempre muito úteis.
Mas, vejo que você apenas está repetindo o que eu disse na minha primeira
mensagem.
Parafraseando seu modo de escrever:
Eu ***JÁ*** sei que é um select for update nowait. Ja identifiquei
Então, achei que estava claro mas pelo jeito não ficou :
a) será que existe uma forma de auxiliá-lo a melhorar a situação?.
A ÚNICA forma segura e adequada é o Fornecedor corrigir a aplicação, não
ficando indefinidamente tentando lockar o objeto, PONTO. Enquanto isso não
ocorre, o que
Tá certo, chefe.
Obrigado.
On Mar 19, 2013, at 12:52 PM, J. Laurindo Chiappa jlchia...@yahoo.com.br
wrote:
Então, achei que estava claro mas pelo jeito não ficou :
a) será que existe uma forma de auxiliá-lo a melhorar a situação?.
A ÚNICA forma segura e adequada é o Fornecedor corrigir
Bom, vamos começar respondendo à sua pergunta : Não, em princípio afaik
(salvo alguma alteração PESADA, não-suportada e EXTREMAMENTE perigosa de
interferir no banco como um todo, tipo via parâmetros internos, OU então
jogando-se o parâmetro de compatibility lá embaixo pra alguma versão
Chiappa, o meu espanto é devido à lógica utilizada na aplicação.
Se o registro está lockado, o processo entra em um loop e tenta novamente
executar exatamente o mesmo select for update nowait para lockar o registro.
O efeito cascata disso é que, ao fazer isto, a sessão A não libera os registros
Hmmm, peraí : nunca vai sair é absolutamente Falso : o lock que A está
mantendo (e que impede B de lockar o mesmo recurso) *** NÃO *** é Eterno, ele
VAI SIM ser liberado assim que A encerrar a transação, seja com COMMIT seja com
ROLLBACK, yes ??? Da mesma maneira, dizer que é impossível
Só para mostrar que *** Não É Verdade *** que vc não possa identificar as
sessões que estão Esperando para obter um lock, veja o Exemplo abaixo (em 11gr2
EE, mas em princípio Independente de versão) : terei 3 janelas separadas (e
portanto 3 sessões) que vão rodar a mesma rotina que não trata
Chiappa,
Agradeço o tempo que você despendeu para analisar o caso, mas devo discordar
totalmente de você, amigo.
1. Veja, não há nenhuma sessão esperando nada.. o select for update está usando
NOWAIT, que é justamente para não esperar.. Ocorre o ORA-00054, e a aplicação
tenta bloquear o
E uma curiosidade : como as sessões 2 e 3 estão Constantemente enviando
pedidos de lock não satisfeitos, paralelemante, quando a Transação que obteve o
lock encerrar, NÂO É NECESSARIAMENTE a segunda sessão que vai receber o lock ,
é aleatório, já que ambas estão enviando constantemente
Nope, veja as minhas outras msgs com demonstrações (que provavelmente não te
chegaram antes de vc escrever esta), que :
- é CLARO que as sessões estão SIM esperando por algo, sessão que não espera
por nadaé IMPOSSÍVEL
- é Claro que (ao menos desde a introdução do 10g) o banco Registra
10 matches
Mail list logo
