ADO Memoryleak / Speicherleck ?!

[OlafSt]

Nur zur Erinnerung: Die ADOConnection ist NICHT threadsafe. Jeder Thread benötigt eine eigene Connection. Ist IIRC auch bei FireDAC so.

[markusef]

Es gibt nur diesen einen Thread, davon gibt es keine weiteren Instanzen, deshalb musste ich mir an dieser Stelle über Multithreading keine Gedanken machen.
Tdatabaseinfo ist eine TDataModule abgeleitete Klasse, die VCL benutze ich nicht da es ein reiner Windows Service ist
Momentan kann ich mir nur noch Erklären das der Fehler in der ADOConnection selbst liegt, da ja sonst keinerlei Aktionen mit dieser Connection getätigt werden außer die Verbindung zu öffnen und wieder zu schließen.

RE: Habe das ganze jetzt nochmal in ein eigenes Projekt ausgelagt um in ruhe daran rumzuexperimentieren.

Aufbau: habe eine VLC Form mit start Button, der Button startet einen Thread welcher wiederrum in der Execute Methode eine TADOConnection created, connected, disconnected, freeAndNil`t.
Ergebnis = gleiches Problem :-/

Reportmemoryleaksonshutdown bringt keinerlei Meldung. Habe es im FormShow auf true gesetzt. ?!

Code:

Code:

unit Unit8;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, ActiveX, Data.Win.ADODB;

type

  TWorkerThread = class(TThread)
    private
      txt            : String;
      ADOConnection  : TADOConnection;

      procedure Sync;

    public
      constructor create;
      destructor destroy; override;
      procedure execute; override;
  end;

  //--------------------------------------------

  TForm8 = class(TForm)
    btnStart      : TButton;
    mmo           : TMemo;

    procedure btnStartClick(Sender: TObject);
    procedure FormShow(Sender: TObject);

  private
    fStarted      : Boolean;
    fThread       : TWorkerThread;

  public
    { Public-Deklarationen }

  end;

  //--------------------------------------------

var
  Form8: TForm8;

implementation

{$R *.dfm}


procedure TForm8.FormShow(Sender: TObject);
begin
  fStarted := false;
  mmo.Clear;
  ReportMemoryLeaksOnShutdown := true;
end;

procedure TForm8.btnStartClick(Sender: TObject);
begin
  if fStarted then
  begin
    fThread.Terminate;
    fThread.WaitFor;
    FreeAndNil(fThread);
    fStarted := false;
    btnStart.Caption := 'Start';
  end
  else
  begin
    fThread := TWorkerThread.Create();
    fThread.start;
    fStarted := true;
    btnStart.Caption := 'Stop';
  end;
end;

// TWorkerThread -------------------------

constructor TWorkerThread.create;
begin
  inherited create(true);
  FreeOnTerminate := false;
  txt := 'created';
  Synchronize(Sync);
end;

destructor TWorkerThread.destroy;
begin
  txt := 'destroyed';
  Synchronize(Sync);
  inherited;
end;

procedure TWorkerThread.execute;
begin
  inherited;
  try
    CoInitialize(nil);

    try
      ADOConnection := TADOConnection.Create(nil);
      ADOConnection.ConnectionString := 'Provider=MSDASQL.1;Password=PASSWORD;Persist Security Info=True;User ID=ADMIN;Data Source=DB';
      ADOConnection.Open;
    finally
      sleep(1000);

      ADOConnection.Close;
      FreeAndNil(ADOConnection);
      CoUninitialize;
    end;
  except
    on e: Exception do
    begin
      txt := e.Message;
      Synchronize(Sync);
    end;
  end;
end;

procedure TWorkerThread.Sync;
begin
  Form8.mmo.Lines.Add(DateTimeToStr(now) + ' | ' + txt)
end;

end.

[markusef]

keiner eine Idee ?!

[sakura]

Zitat von markusef:

keiner eine Idee ?!

Der gleiche Code - anderer ConnectionString - läuft bei mir ohne jegliche Probleme bzw. Speicherlecks.

......

[HolgerX]

Hmm..

Könnte eventuell mit dem ConnectionPool der ADO-Connection zusammenhängen.

Dieser Pool wird erst freigegeben, wenn ein Timeout ohne Anforderung einer neuen Connection (mit gleichem ConString) abgelaufen ist.

Da je nach Konfiguration der Connection bzw. des Servers hier andere Einstellungen verwendet werden, könnte sich daraus eine unterschiedliche Speichernutzung ergeben.


Nur so eine Idee

[markusef]

Okay, ein weiterer Test beinhaltete folgendes:

Oberer Aufbau, wobei nach 20.000 SELECT-Abfragen automatisch der Thread gestoppt wurde. Nach jedem SELECT wurde die Query wie oben im Quellcode geschlossen und ein FreeAndNil angewandt. Das ganze habe ich diesmal aber auf einer lokalen MySQL Datenbank ausgeführt und einmal auf der SAP MaxDb. Beides über ODBC Treiber.

Ergebnis:

Der Speicherzuwachs tritt nur (!!!) bei der SAP MaxDb auf. Bei der Nutzung der MySQL Datenbank gab es keinerlei Speicherzuwachs.
Demnach muss der Fehler im ODBC Treiber der SAP MaxDb stecken.

[sakura]

Zitat von markusef:

Demnach muss der Fehler im ODBC Treiber der SAP MaxDb stecken.

Muss ist relativ, aber wahrscheinlich scheint es hier zu sein. Andere Treiberversion testen.

......