[firebase-br] FireDac + Firebird: não libera cursor/memória apos Close no FDQuery?

Gladiston Santana gladiston em vidy.com.br
Sex Fev 17 11:27:27 -03 2017


Tem algo conceitual aí.
Na programação OO, objeto criado terá basicamente o mesmo tamanho aberto ou
fechado.
Dê uma olhada na propriedade FDQuery.InstanceSize e verá que o tamanho do
objeto é o mesmo antes ou depois do FDQuery.Open.
Não é um exemplo bom, mas o tipo inteiro terá será sempre o mesmo tamanho
não importa o numero que ele represente.
O mesmo ocorre com os objetos, a diferença é que as ações desses poderá
repercutir no consumo em outras instancias interdependentes, e é nesses que
o consumo aumenta e não no objeto primário de sua discussão.
Toda a operação num banco de dados funciona sob uma transação, até os
open´s, a menos que a transação seja terminada, os eventos que sucederam
provavelmente ainda consomem memória.
BDE era um saco furado jogando memória fora.
O consumo dos datawares por meio da tríada Dataset, Datasource e conexão e
tão vasto que é complicado determinar se o vazamento é neles ou nos
componentes que os consomem. Mas geralmente fecho a conexão e sempre a
memória volta ao ponto zero então sei que a triade tá funcionando a
contento.

[] ´s


Em 17 de fevereiro de 2017 09:24, <thiago.almeida em neainformatica.com.br>
escreveu:

>
>
> Sras e Srs, Bom dia.
>
> Em uma aplicação nossa, percebi algo que
> achei curioso.
>
> Por uma necessidade X, preciso fazer consultas ao banco
> dentro de um loob while (estou falando do Delphi).
>
> Neste loop, eu
> fecho o FDQuery, configuro os parâmetros e abro o FDQuery. Nos testes
> percebemos que esta query dentro do While não está liberando a memória
> ocupada após o .Close (causando um estouro de memória).
>
> A solução que
> encontrei foi desligar o RequestLive, tornando o dataset somente leitura
> (como não faço atualizações através dessa query, não houve problema
> algum).
>
> O caso é que eu fiquei sem entender o que de fato aconteceu.
>
>
> Pode ser que eu esteja enganado, mas até onde sei, quando se abre uma
> query, os dados são carregados e um cache interno (daí vai de cada
> componente) é mantido para que o cursor seja multi-direcional. Contudo
> eu esperava que com o .Close, toda memória alocada fosse liberada junto
> com o cursor. O que podemos identificar é que esse estouro acontece na
> máquina cliente apenas. No servidor, fica tudo tranquilo. O que me leva
> a questionar o FireDac e sua gerência de memória ou o FireDac e a falta
> de um comando para que o client (fbclient.dll) libere a memória/cursor.
>
>
> Alguém já viu isso?
>
> []'s
>
> Francisco Thiago.
>
>
> ______________________________________________
> 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/pes
> quisa_lista.html
>



-- 
--
B em B@BU     iB em M@B.  B em MBBO   MBBMMB em B@BZLr    E@@@@i      r@@@BU
vB em M@O     E em B@Bu   BBBM em 0   G em MMM@N8MBB em ZP5r  B em B@k      8B@@O
 OB em B@q   2 em BBBM    B em B@BO   BB em B@B,.:,7B em B@@L uB em B@,    OB em B@.
 ,@@@B@   @BBB@,    @BBB em 8   M em M@@@     PB em B@B  @@@BN   iB em B@L
  U em B@B2 LB em B@X     B em MBBO   MBBM em B     i em BBB@. 7 em B@Bi  B em B@E
   B@@@BiM em M@B.     @BBM em G   M em MMB@     v@@M em B,  G em B@Z v em B@B.
   7B em B@O em B@B5      B em B@B8   BBBM em B     Z@@@B@   iB@@@2 em B@Br
    NB em M@B em B8       @B em B@8   M em B@B em i:i75 em B@B em r    E@@B em B@Bq
    . em B@@@B@:       B em B@B@   @B@@@B em B@B@@@ME;     .BB em MBB@
     55.ANOS        OMOGBS   PBZGGOOMOO117,        7 em BBB@r
     ==============================================r@@@@F=====
     Gladiston Santana                             8 em B@B,
     Supervisor de TI                             G em B@B7
     Tel.:+551147873122 R:228                    :@B em B0
     Grupo VIDY - SGQ ISO9001 - 55 ANOS          @B em B@.
     Visite nosso site: www·vidy·com·br         BB@@@u
     Visite também : www·expolabor·com·br      GB em B@N



Mais detalhes sobre a lista de discussão lista