Da hilft eigentlich nur schrittweise Teile des Codes zu entfernen (z.B. die
TCP/
IP Teil) und die Funktion zu simulieren um den Rest der Anwendung einem Stresstest zu unterziehen.
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.
Ja, das kenn ich gut, "geht doch viel einfacher so", "wenn tatsächlich neue Anforderungen kommen machen wirs richtig..." usw., nur zahlt man so bei Fehlersuche und späteren Erweiterungen drauf.
Ein automatischer
Unit-Test scheint mir in der jetzigen Struktur kaum möglich.
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...
Das erscheint mir zumindest nicht klar. Es kann durchaus sein, daß der Zugriff auf die Datenbank länger dauert als normal. Im schlimmsten Falls ist die Verbindung zum
DB-Server/Dienst gestört.
Falls dann tatsächlich zwei Anfragen kurz nacheinander abgeschlossen werden, existieren plötzlich auch zwei TDBEntryThread, aber nur eine Connection...