Minha impressão é que uma transação ficou perdida, causando um tempo de
aguardo até o desbloqueio, mas como está "perdida" dará dead lock no final
do processo.
Como há a impressão de "congelamento", ao parar o serviço e reiniciar, você
acaba matando todos os processos, incluindo o causador, a transação
pendente.
Mas é temporário até que o processo repita novamente, teria de descobrir
onde no programa abre uma transação que não culmine no commit.
Temporariamente, você poderia colocar no seu programa, no onclose algo
assim:
procedure TfmXXXXX.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
try
Application.OnHint := nil;
if (dm.MyConn.Connected) then
begin
if Assigned(dm.MyConn.Transaction) then
begin
if dm.MyConn.Transaction.Active then
begin
dm.MyConn.Transaction.Commit;
end;
end;
if dm.FB_TRANSACTION_RW.Active then
begin
dm.FB_TRANSACTION_RO.Commit;
end;
if dm.FB_TRANSACTION_RO.Active then
begin
dm.FB_TRANSACTION_RO.Commit;
end;
if dm.MyConn.Connected then
dm.MyConn.Close;
end;
finally
CanClose:=true;
end;
end;
Algo que também poderia ser feito é escrever um arquivo de log de quando
uma estação conectou seu app e quando desconectou, isso daria indicios de
que tem um usuário matando seu app através do gerenciador de tarefas, algo
que faria uma transação ficar eternamente aberta. As vezes o usuário
(sempre ele), acha que um processamento tá demorando tempo demais, daí como
ele é "hacker", aprendeu a matar a tarefa e iniciar de novo, algo que com o
BD conectado não se deve fazer.
Mas tudo isso é um chute, e um bom chute.
Como o João Marcos disse, você é guerreiro e acredita até o fim.
Vou ser franco com você, o que conseguiu até o momento é uma proeza que só
conseguistes porque usa o principio da conexão e desconexão.
Obteria resultados muito melhores com Datasnap, menos dor de cabeça e mais
performance. A principio porque com o Datasnap, você trabalha offline até
resolver fazer o sync com o banco, provavelmente numa ação de "Salvar" ou
ao fechar o form.
Não vale a pena aprender datasnap por autodidatismo, quebra muito a cabeça
assim, vale mais a pena pagar por um curso online ou presencial(melhor) e
por a mão na massa com a certeza do acerto.
[]´s
Em 10 de fevereiro de 2017 13:33, Carlos Andrade <krlosgilson em gmail.com>
escreveu:
> Olá a todos! Eu possuo um sistema em Delphi espalhado em mais ou menos 50
> clientes dentro de um mesmo estado. Cada cliente possui na média de 4
> computadores. A aplicação abre a conexão ao firebird via internet por ex:
> "firebird.dominio.com.br:/firebird/BANCO.FDB". O servidor é um VPS e
> possui um Linux/Debian 7.0 e o Firebird é o 2.5 Superclassic. A aplicação
> faz assim: Abre a conexão ao logar -> fecha a conexão e a cada requisição,
> abre novamente a conexão e fecha. No decorrer de 5 anos eu já tenho
> modificado muita coisa sempre procurando melhorar a performance e
> atualmente esta é a que ficou mais estável. Só que, de uns meses pra cá,
> vem acontecendo o seguinte todos os dias... O firebird simplesmente congela
> e a partir desse momento não aceita nenhuma requisição como "select",
> "insert", "update" e "delete", mas ele aceita novas conexões. Quando isso
> ocorre, conecto no VPS e verifico como está o uso da memória, processador e
> HD, e todos estão exatamente normais, uso do cpu fica em torno de 5%,
> memória abaixo da metade e HD também. Esse problema é corrigido apenas
> quando reinicio o serviço do firebird assim: "/etc/init.d/firebird2.5-superclassic
> restart". Com isso, tudo normaliza e no outro dia acontece novamente. O que
> pode estar ocasionando isso?
>
> Eu já ouvi falar em 3 camadas, mas não tenho muita noção de como fazer e
> se também iria melhorar a performance.
>