IdHTTPServer im Thread - Synchronität im OnCommand zum Thread

[Hobbycoder]

Hi,

ich habe mal eine Verständnisfrage zum IdHttpServer. (Vielleicht ist das Blödsinn, aber ich frag einfach mal so in der Runde).

Meines Wissens wird ja jede Anfrage an den TIdHttpServer in einem vom ihm selbst erzeugten Thread abgearbeitet. D.h. das alles, was im OnCommand-Event abläuft, ja auch in eben diesem Thread-Context läuft.
Ich lasse den TIdHttpServer gerne selbst schon in einem Thread laufen, damit er vom Mainthread entkoppelt ist, und weil es sich später leichter in einen Service überführen lässt.

Nun habe ich in meinem Thread natürlich auch Daten, die durch die Webanfragen gehändelt werden müssen (Insert, Update, Delete, etc). Als Beispiel mal eine einfache TObjectList.
Die Frage nun, in wie weit muss ich das innerhalb des OnCommand absichern, da ja ggf. zeitgleich 2 oder mehr Anfragen bearbeitet werden könnten, die dann auch gleichzeitig in den Daten rumwurschteln.
Hier mal ein kleines Bisschen Beispielcode:

Delphi-Quellcode:

unit thWebserver;

interface

uses System.Classes, System.SysUtils, IdHTTPServer, IdContext, IdCustomHTTPServer, System.Generics.Collections;

Type
  TOnLog=procedure(Sender: TObject; LogText: string) of object;

  TTestData=class
  private
    FID: Integer;
    FWert: Extended;
    FBeschreibung: string;
    procedure SetID(const Value: Integer);
    procedure SetWert(const Value: Extended);
    procedure SetBeschreibung(const Value: string);  
  published
    property ID: Integer read FID write SetID;
    property Wert: Extended read FWert write SetWert;
    property Beschreibung: string read FBeschreibung write SetBeschreibung;
  end;

  TTestDataList=class(TObjectList<TTestData>)
  public
    function ItemOfID(value: Integer): TTestData;
  end;

  TTestThread=class(TThread)
  private
    FOnLog: TOLog;
    FTestDataList: TTestDataList;
    procedure DoLog(LogText: string);
    procedure AddData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
    procedure ModifyData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
    procedure DeleteData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
    procedure OnCommand(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
  public
    constructor Create(Suspended: Boolean; Port: Integer; OnLog: TOnLog);
  protected
    procedure Execute; override;
  end;

implementation

{ TTestData }

procedure SetID(const Value: Integer);
begin
  FID := Value;
end;

procedure SetWert(const Value: Extended);
begin
  FWert := Value;
end;

procedure SetBeschreibung(const Value: string);  
begin
  FBeschreibung := Value;
end;

{ TTestDataList }

function ItemOfID(value: Integer): TTestData;
var
  I: Integer;
begin
  Result:=nil;
  for I:=0 to self.Count-1 do
    if self[i].ID=value then
    begin
      Result:=self[i];
      Break;
    end;
end; 

{ TTestThread }

procedure DoLog(LogText: string);
begin
  if Assigned(FOnLog) then
    synchronize(procedure
    begin
      FOnLog(self, LogText);
    end);
end; 

procedure AddData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
  T: TTestData;
  wert: Extended;
  bescheibung: string;
begin
  wert:=StrToFloat(ARequestInfo.Params.Values['wert']);
  bescheibung:=ARequestInfo.Params.Values['bescheibung'];
  T:=TTestData.Create;
  T.ID:=Random(10000);
  T.Wert:=wert;
  T.Beschreibung:=beschreibung;
  FTestDataList.Add(T);
  DoLog('Add Data');
end;

procedure ModifyData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
  T: TTestData;
  wert: Extended;
  bescheibung: string;
  id: Integer;
begin
  id:=StrToInt(ARequestInfo.Params.Values['id']);
  wert:=StrToFloat(ARequestInfo.Params.Values['wert']);
  bescheibung:=ARequestInfo.Params.Values['bescheibung'];
  T:=FTestDataList.ItemOfID(id);
  if T<>nil then
  begin
    T.Wert:=wert;
    T.Beschreibung:=beschreibung;
  end;
  DoLog('Modify Data');
end;

procedure DeleteData(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
  T: TTestData;
  id: Integer;
begin
  id:=StrToInt(ARequestInfo.Params.Values['id']);
  T:=FTestDataList.ItemOfID(id);
  if T<>nil then
    FTestDataList.Remove(T);
  DoLog('Delete Data');
end;

procedure OnCommand(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
begin
  if ARequestInfo.Document='/AddItem' then
    AddData(AContext, ARequestInfo, AResponseInfo) else
  if ARequestInfo.Document='/ModifyItem' then
    ModifyData(AContext, ARequestInfo, AResponseInfo) else
  if ARequestInfo.Document='/DeleteItem' then
    DeleteData(AContext, ARequestInfo, AResponseInfo);
  AResponseInfo.ContentType:='text/text';
  AResponseInfo.ContentText:='OK';
  AResponseInfo.ResponseNo:=200;
  AResponseInfo.ResponseText:='HTTP/1.0 200 OK';
end;

constructor Create(Suspended: Boolean; Port: Integer; OnLog: TOnLog);
begin
  inherited Create(Suspended);
  self.FPort:=Port;
  self.FOnLog:=OnLog;
end;

procedure Execute;
var
  FHttpServer: TIdHTTPServer;
begin
  FHttpServer:=TIdHTTPServer.Create(nil);
  FTestDataList:=TTestDataList.Create(True);
  try
    FHTTPServer.DefaultPort:=FPort;
    FHTTPServer.AutoStartSession:=True;
    FHTTPServer.SessionState:=True;
    FHTTPServer.ParseParams:=True;
    FHTTPServer.SessionIDCookieName:='TeestServer';
    FHTTPServer.OnCommandGet:=OnCommand;
    FHTTPServer.Active:=True;
    FHTTPServer.StartListening;
    While not self.Terminated do
      sleep(20);
    FHTTPServer.StopListening;
  finally
    FHTTPServer.Free;
    FTestDataList.Free;
  end;
end;
   
end.

(Nur Beispiel - Hab ich hier im Editor zusammengeschrieben)

Das ist mal ganz kurz ohne jegliche Try..Except und so weiter.
Mir geht es explizit um die Methode OnCommand, wenn jetzt gleichzeitung von zwei Usern /ModifyItem und /DeleteItem aufgerufen werden würde. So könnte der eine grad am Bearbeiten des TObjects sein, während der andere das gleiche Object mal eben freigibt. Theoretisch würd's ja dann knallen.
Muss man das noch zusätzlich schützen? Und wenn ja, wie?

Oder ist es so, dass der TIdHTTPServer die jeweilgen Anfragen zwar gleichzeitig annehmen kann, jedoch die OnCommand-Events der Abfragethreads serielle verarbeitet?

Ich hoffe ich habe verständlich ausgedrückt was ich meine.

[Der schöne Günther]

Dein Thread ist nicht notwendig. Das siehst du im Execute() ja selbst, der macht nichts, außer ständig zu schlafen und aufzuwachen und wieder zu schlafen.

Du liegst völlig richtig, dass nichts "verhindert", dass der Server auch mehrere Anfragen gleichzeitig bearbeiten würde die auf dem gleichen Datenbestand arbeiten - Deshalb muss man das entsprechend absichern. Entweder übersehe ich etwas, aber ich sehe das nicht auf Aufgabe des Servers, dessen Aufgabe ist ja nur, über Http die Daten entgegen zu nehmen, zu interpretieren und meinetwegen dann etwas entsprechendes auszulösen. Deine Klasse die sich z.B. um deine beispielhafte ObjectList kümmert sollte damit klarkommen, bzw. so gebaut sein, dass sie sich parallel ansprechen lässt und der Datenzustand konsistent ist. Siehe z.B.: https://de.wikipedia.org/wiki/ACID

[Olli73]

Alle Zugriffe auf die ObjectList absichern mit TMonitor, TCriticalSection, TMultiReadExclusiveWriteSynchronizer oder Ähnlichem...

[himitsu]

oder TThreadList usw.

[udo888]

Sorry, wenn ich mich hier gleich einmal anschließe.
Mein Thematik schein ähnlicher Art zu sein und als oller Datenquetscher bin ich gerade dabei, mich ein wenig mit dem TIdHTTPServer zu beschäftigen. Horizonterweiterung, vielleicht springt eine Idee heraus. Ich bin also mit dem Thema nicht dolle vertraut.

Ich übergebe dem TIdHTTPServer aus dem lokalen Netz einen Aufruf mit einer Funktionsnummer und ein paar weiterer Variablen. Die Funktionsnummer läuft über ein Case und ruft dann die entsprechende Funktion auf, die mir über Datenbankabfragen mein gewünschtes Ergebnis zurück liefert.

Irgendwie logisch, dass es irgendwann knallt, weil die DB-Abfragen nicht threadsicher sind.
Eine threadsichere Umprogrammierung steht gar nicht in Aufwand und Nutzen, dazu ist das Projekt über gefühlte 150 Jahre historisch gewachsen.

Die einzelnen Abfragen dauern kaum ein paar Millisekunden, es steht einer sequentiellen Abarbeitung nichts im Wege. Ist überhaupt nicht zeitkritisch.


Jetzt meine Fragen. Wie kann ich es gestalten, dass meine über das Case der Funktionsnummern gestarteten Aufrufe in aller Ruhe nacheinander abgearbeitet werden? Da gibt es zwar Synchronisize, wann und wie muss/soll ich das verwenden?

Gibt es andere Möglichkeiten, die sequentielle Verarbeitung zu erzwingen? Zentral eine Variable hochzählen und erst weitermachen, wenn diese abgeräumt ist?


Hier bisschen Quelle:

procedure TTsMain.HTTPServCommandGet(AThread: TIdPeerThread;
ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
sb : String;
fkt : Integer;
tsq : TStrings;
begin
sb:= '';
fkt:= -1;
tsq:= ARequestInfo.Params;
if Assigned(tsq) then begin
fkt:= IntValues(tsq,CWsFunc);
case fkt of
001 : sb:= Mitteilung(fkt);
010 : sb:= PersonalAnmeldung(tsq);
011 : sb:= PersonalAnmelden(tsq);
101 : ... usw

end;
end;
AResponseInfo.ContentText:= sb;
end;

Vielleicht hat jemand einen einfachen Lösungsvorschlag?

[QuickAndDirty]

@udo888
Bitte schön die Holzhammermethode

Delphi-Quellcode:

var DB_CS:TCriticalSection; // Globale CriticalSection für DB operationen am besten in eigener unit im initialize erzeugen
                            // Aber jetzt steht sie halt hier...es darf nur die eine geben um es einfach zu halten
                            

procedure TTsMain.HTTPServCommandGet(AThread: TIdPeerThread;
                                     ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
   sb : String;
   fkt : Integer;
   tsq : TStrings;
begin
   sb:= '';
   fkt:= -1;
   tsq:= ARequestInfo.Params;
   if Assigned(tsq) then 
   begin
      fkt:= IntValues(tsq,CWsFunc);
      DB_CS.Aquire; // Alle anderen DB_CS.Aquires warten bis DB_CS.Release 
                    // von dem thread mit der Aktiven Critical Section aufgerufen wird.
                    // Du hast jetzt 0% Nebenläufigkeit....
      try
         case fkt of
            001 : sb:= Mitteilung(fkt);
            010 : sb:= PersonalAnmeldung(tsq);
            011 : sb:= PersonalAnmelden(tsq);
            101 : ... usw

         end;

      finally 
          DB_CS.release;
      end;   
   end;
   AResponseInfo.ContentText:= sb;
end;

Richtig wäre es gewesen pro thread eine eigene Datenbankverbindung aufzumachen. bzw. Das Datenbankverbindungsschwimmbecken zu nutzen

[himitsu]

Aufwand?

* entweder hat die Connection-Komponente für die DB z.B. in aktivierbares Thread-Pooling
* oder einfach in jedem Thread eine eigene Connection-Komponente erstellen, welche dann von den verwendeten Query-Komponenten genutzt wird (als Parameter Jenen übergeben).

* oder der problematische Code wird mit einer CriticalSection abgesichert, damit eben immer nur Einer gleichzeitig diese Connection benutzt

* oder via Synchronize in den Hauptthread und dort diesen Code-Teil ausführen

* oder ...

[udo888]

Erst einmal vielen Dank für die Holzhammermethode. Augenscheinlich hat es geholfen!

Wenn die Grundlagen der Datenbankzugriffe nicht sooo alt wären, hätte ich das threadsicher umgestellt. Wir reden hier mal locker von 25 Jahren mit direkten Btrieve-Zugriffen.
Never change a running system.

Danke!