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

oder TThreadList usw.

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?

@udo888
Bitte schön die Holzhammermethode

zusammenfalten · markieren

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

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 ...

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!