Error en hilos de ejecución

[cmfab]

Bueno, sigo sin poder resolver el problema. El consumo excesivo de la memoria está en el hilo, ya lo he reprogramado de muchas maneras, he usado un Timer sin el hilo y todo sigue mal. no veo que se queden sin liberar recursos, en el resultado de la instrucción

Código Delphi [-]
ReportMemoryLeaksOnShutDown := True;

lo que tengo en esta clase son 6 strings con contenidos SQL, no se porque me hace referencia a ellos. acá el código de la clase del hilo

Código Delphi [-]
Tbquix_hilo = Class(TThread)
    Constructor Create(ConnectionString,SQL1,SQL2,SQL3,SQL4,SQL5,SQL6:String; tipoT:Integer);
  private
    FSQL1,FSQL2,FSQL3,FSQL4,FSQL5,FSQL6: String;
    FConnection: String;
    FTipoT:Integer;
    Data1,Data2, Data3, Data4,Data5, Data6: TADODataset;
  Protected
    Procedure Execute; override;
  public
    Property DataCheqDet: TADODataset read Data1 write Data1;
    Property DataCheq: TADODataset read Data2 write Data2;

    Property DataFactDet: TADODataset read Data3 write Data3;
    Property DataFact: TADODataset read Data4 write Data4;

    Property DataCMDet: TADODataset read Data5 write Data5;
    Property DataCM: TADODataset read Data6 write Data6;
  End;

la definición del constructor

Código Delphi [-]
constructor Tbquix_hilo.Create(ConnectionString,SQL1,SQL2,SQL3,SQL4,SQL5,SQL6:String; tipoT:Integer);
begin
  inherited Create(false);
  FConnection := Connectionstring;
  FSQL1 := SQL1;
  FSQL2 := SQL2;
  FSQL3 := SQL3;
  FSQL4 := SQL4;
  FSQL5 := SQL5;
  FSQL6 := SQL6;
  FTipoT := tipoT;
end;

y el método de ejecución

Código Delphi [-]
procedure Tbquix_hilo.Execute;
begin
  inherited;
  CoInitialize(nil);
  if (FtipoT = 0) or (FtipoT = 1) then begin
        Data1 := TAdodataset.Create(Application);
        Data1.ConnectionString := FConnection;
        Data1.commandtext := FSQL1;
        Data1.Open;
  end;
  CoUnInitialize;
end;

y cuando el hilo termina lo único que hago es leer los datos de ADODataset y copiarlos a un TClientDataset, después libero los objetos con esta instrucción:

Código Delphi [-]
Tbquix_hilo(Sender).DatacheqDet.Free;

y así para las 6 consultas, parece muy básico y sencillo.

no tengo idea porque se dispara la memoria, no actualizo controles de la VCL en el hilo, no uso variables globales. Que puede estar pasando ?.

[Neftali [Germán.Estévez]]

Falta código y todavía quedan dudas...

¿Los elementos que creas en el hilo, dónde los destruyes? (por norma lo que se crea en un sitio se destruye en ese mismo sitio

¿Utilizas Shyncronize?
¿Porqué no usas elDestroy del hilo?
No me queda claro que hagas el CoUnInitialize y luego continues trabajando con el Dataset (yo lo pasaría al Destroy).

[cmfab]

Buenos días.

Cuando el hilo se termina el Dataset creado en el mismo se destruye con la instrucción que puse anteriormente.

Los hilos se crean con la instrucción

Código Delphi [-]
FreeOnTerminate := True

, por lo cual deduzco que la propia clase hace el trabajo.

No uso el método Synchronize, puesto que lo único que hago es cuando el hilo termina y me devuelve los datos de la consulta es insertarlo en un TClientDataSet

[hal1967]

Siendo que pasasen el constructor "TFDConnection"

realmente no se que más hay con esa conexión (otros dataset o grillas). Asegurate que solo se use en ese hilo,
o no la pases al constructor, solo creala dentro del hilo.

Código Delphi [-]
constructor THiloCheque.create (cone: TFDConnection; const SQL: String);

Puedes hacerlo como prueba, ignora el pase de parámetros y creala en el constructor, y la destruyes en el destroy.

[cmfab]

Ok, Gracias, revisaré como se propone. aunque hay acá al parecer otro tema después de tantos quebraderos de cabeza, y es que algo no anda bien con el propio ODBC del proveedor, cuando hago una sola conexión la app funciona mejor, pero cuando hago conexiones dinámicas y las destruyo, ahí consume más recursos. Estoy haciendo pruebas al respecto.

[mamcx]

El problema de fondo es que la estructuración que tienes no es la ideal para multihilos. La mayoría de los lenguajes no ayudan tampoco, incluido Delphi.

Yo haría lo siguiente:

- Anula por ahora lo de multihilos
- Convierte el código en una maquina de estados. Asegurate de PASAR DATOS(valores) y no POINTERS. En donde haces una transferencia, clona información.

Una vez tengas limpio el código y andando lo pones y te sugerimos como estructúralos para hilos...

[hal1967]

Recuerda una conexión a una base de datos no es Threadsafe. Es posible que estás a mitad de una consulta y entre otro hilo (o el principal) y se cruce. Al servidor llegaría algo como "SELECT * FROM UPDATE ...".


Eso no solo pasaría con ODBC, pasaría con cualquiera.



Los servidores son threadsafe por que cada conexión es un hilo, pero no deberías tener en la misma conexión varios hilos al menos que trabajes con sincronización o locks (lo cual puede ser frustrante).


A otro nivel, a mi me ha tocado trabajar con cientos de hilos y es espetacular cuando funciona bien y de forma eficiente. No tienes porque crear un hilo, consultar y destruirlo, lo puedes volver a utilizar, lo creas en pausa con todos sus conexiones y dataset, cuando lo requieras start, cuando cierres tu aplicación liberas los hilos (previamente detenidos). La otra forma es que tengas un ciclo dentro del hilo, y al cerrar tu app, terminas previamente los hilos.


Si optas por algo de esto, no olvides, todo hilo debe ejecutarse al menos una vez, caso contrario dejas memoria en mal estado.

[cmfab]

Solución.

Bueno definitivamente el tema se ha solucionado (al menos en las últimas 24 horas) aumentando el tiempo de las conexiones de 20 a 60 segundos, por lo que al parecer el controlador ODBC requiere de tiempo quizá para liberar recursos. aún no he puesto la pregunta en la web de soporte del proveedor, pero casi seguro que por ahí anda el tema.

Gracias a todos por sus recomendaciones y opiniones.

[Neftali [Germán.Estévez]]

Empezado por cmfab

Cuando el hilo se termina el Dataset creado en el mismo se destruye con la instrucción que puse anteriormente.
... por lo cual deduzco que la propia clase hace el trabajo.

Has creado los Datasets usando como Owner, el objeto Application, por lo tanto deberías revisar ese comportamiento.