Die lieben Threads mal wieder, es Fehlert so rum

[Medium]

Die Connection hatte ich auch schon unter Verdacht, da die schon mal mein Problem mit Threads war - daher die eigene Connection für den TFetchThread, beim DBEntryThread hab ich das vergessen. Das wäre auch schon gefixed gewesen, wenn nicht schon die Variante von DBEntryThread, die überhaupt nichts macht die ganzen Fehler beim Create werfen würde! Das ist der Teil, an dem ich den ganzen Tag verzweifel: Das bloße Erzeugen eines Threads, der wirklich nichts tut, also komplett leere Execute-Methode und leerem Konstruktor (bis auf das von Blup angesprochene) führt zu den genannten Random-Fehlern. Und zwar nicht in einer der 3 Zeilen im Konstruktor, sondern erst in der Methode, die den Konstruktor aufruft - dort aber unmittelbar in dieser Zeile. Aus diesem Grunde bin ich von den DB Dingen erstmal weg, weil eben auch ganz ohne rummst es schon unverändert. Wenn das dann mal gelöst ist, bekommen die auch ihre eigene Connection, oder eine gesharete mit Critical-Sections (dürfte deutlich performanter sein; alternativ Pooling an).
Der Witz ist ja, dass sogar die Variante mit voller Funktionalität (also incl. DB Zugriffen) klaglos tut, wenn das Erzeugen denn geklappt hat. Vermutlich eher Zufall, aber dort habe ich noch nie eine Exception gesehen. Der Hund ist im reinen Erzeugen des Threads begraben, und dort auch nur mit einer Häufigkeit von grob geschätzt 5-15% der Erzeugungen. Laut Taskmanager habe icha uch keine Probleme mit zu vielen Handles oder Threads, so lange das Programm läuft, bleibt die Anzahl derer im Mittel gleich. Daher scheinen die auch korrekt zu terminieren.

Ich habe den Weg mit nur einem Abarbeitenden Thread gewählt, weil leider die Zurordnung "Anfrage zu Antwort" nicht möglich ist (danke Siemens...), und es einfacher erschien einen einzelnen Thread warten zu lassen bis die Antwort zur letzten Anfrage da ist, als dies zwischen mehreren Threads (einer pro Anfragegruppe, oder gar dynamische Worker) zu synchronisieren. Die DB-Einträge sind eigentlich nur deswegen in einen weiteren Thread ausgelagert, da in der Zeit, in der das Update zusammengebastelt und ausgeführt wird ja ruhig schon die nächste Anfrage los gehen kann. Der Kram im DBEntryThread fand zuvor komplett im Kontext des TFetchThreads statt, hat diesen aber unnötig aufgehalten.
Und da eh klar ist, dass ich immer nach einer Anfrage auf Antwort warten muss, erschien mir die Variante mit einer Joblist für die DB Einträge überflüssig - da könnte eh immer nur einer drin stehen, also kann ich auch gleich direkt einen Thread zur aktuellen Antwort abfeuern. Eigentlich...