Das ehrt deine Programmierkünste hilft aber Ende nicht allzuviel.
Läuft in dem Thread der Anwendung der Webserver?
Du bist in der Situation aus Sicht der Anwendung dass du viele Formulare offen hast auf denen ein Timer sitzt der per Zufallszahl einen ButtonClick resp. eine andere Ereignisbehandlung auslöst. Da hilft es auch nicht viel wenn du den 'Webserver' in der Anwendung laufen hast, denn du musst dauern den
GUI Thread unterbrechen.
Eigentlich wäre deine Applikation am PC eine Anwendung die vom 'Server' gestartet wurde und nicht umgekehrt.
Du kannst einen Thread machen der eine
DB Operation nach der anderen durchführt. Es macht auf jeden Fall Sinn den Empfang der Nachrichten von der Verbuchung zu entkoppeln. Schreibe die empfangene Nachricht in eine File und verbuche sie im Hintergrund.
Sobald du mit Messages und Queuing arbeitest sagst du zurecht der Anwendung ist egal was mit den Daten passiert, sie übergibt nur an den der die Daten weiterschickt und der weiß schon wohin.
Critical Section bieten sich. Ich würde aber nicht soweit gehen, dass ich unter der Kontrolle einer Anwendung mehre Nachrichten empfangende Threads mache die dann mit einem Pool von
DB Writer und
DB Reader Prozessen kommunizieren.
Da hast du bspw. in PHP denn in dem Fall synchronisiert der Runtime die
DB Sessions.
Ich persönlich würde diese Verarbeitung hinter einen isoliert laufenden Webserver stecken. Damit hat du zumindest den Empfang vom Verbuchen entkoppelt.
Critical Sections bieten sich zur Synchronisation an.
Die Kommunikation mit den Clients läuft ja schon perfekt (via Webserver Multi-Thread).