Was heißt denn hängen/festkleben?
Bzw. warum hängt der denn?

Gerade in einem Service, vorallem wenn der länger läuft, sollte man beser alles ordentlich beenden und vorallem die Resourcen richtig freigeben, was durch Abschießen praktisch nicht möglich ist.


PS: Da du natürlich keine Resourcenschutzblöcke verbaut hast, gibt es bei einer Exception einen geilen Deadlock in deiner aCriticalSection.

festkleben heisst, dass eine Stored Proc nie wieder kommt und UniDAC für immer wartet. Das blockiert den Thread.

aCriticalSection ist eine globale variable im MainThread, welche beim erstellen des Services erzeugt wird und auch wieder freigegeben wird.
Und die Option des Abschiessens ist nicht... ähm... optimal, aber eine stored proc in dem Kontext sollte nie länger als 1-3 Sekunden dauern, wenn es länger dauert, dann ging was unerwartetes schief und ich muss das mit einbedenken.

Wie kann denn eine SP nie zurückkommen? Die Frage sollte mit 'NIE' beantwortet werden.

Eine option ist zum Bsp. die WAIT Transaction, die nicht einen lock conflict herbeiführt, sondern wartet bis die andere ihre updates abgschlossen hat. Hatte Falle wo niemand mit einer DB verbunden war und ich die SP nie zurück kam in der WAIT transaction. eine NO_WAIT brachte sofort einen lock conflict, obwohl niemand dort war. Ein Neustart von Firebird brachte die Lösung.

UniDAC hat keine Option, "normal" zu beenden mit TimeOut oder so. UniDAC blockiert immer den ganzen Thread.

Mein Beitrag ging in die Richtung: Dann würde ich diese Implementierung überdenken bzw. dafür sorgen, das eine Query/SP nie hängt. Das sollte mit FB doch zu machen sein.

"Abschießen" o.ä. ist jedenfalls die unsauberste aller Implementierungsoptionen.

Alternativ kann man sich asynchron verbinden und die Verbindung bei Zeitüberschreitung beenden. Ob das mit UniDAC geht, weiß ich nicht.

Edit: Ich verstehe zwar nicht genau, was der TE mit 'DB' meint, und das ein Thread sich DBs teilt, aber grundsätzlich würde ich das nicht so lösen, sondern über einen Connectionpool. Pro Anfrage ein Thread, die sich aus dem Pool bedienen. Das löst das Problem zwar nicht, dürfte aber um vieles einfacher sein.

Es ist ein Connection Pool, aber ich mache nicht pro Anfrage ein thread, weil das viel zu lange dauert. Manchmal habe ich nach einer Kostenneuberechnung im System ein paar tausend Dokumente neu zu buchen in der Buchhaltung (deren Bewegung vom Inventarkonto zum Ausgabenkonto). Pro Dokument kann das in total schonmal 1-2 Sekunden dauern. Wenn ich für jede von diesen Aufgaben enen neuen Thread machen wurde, wäre der Overhead an Zeit einfach zu gross. Ich kriege ja schon Mecker vom Chef, weil ich die nicht im Block abarbeite, sondern ene transaktion für jede mache und mir in Sammelthreads sogar noch zeit für andere DBs nehme

Klar, die beste Lösung ist wenn die SP nie hängt, aber das schafft man auch nur zu 99%. Da kommen viel Faktoren mit rein. Versuche nur, an alles zu denken und auch die 1% abzudecken
Unsere DB hat knapp 400 stored procs und ein paar hundert Trigger. In Kombination mit den Daten kann es da zu seltsamen zusammenspielen kommen, die man nicht im vorraus sieht.

Oh.. Also 'as is'. Na ja. Dann muss man es eben so machen.

Wie wäre es mit Workerthreads, die eine Jobliste abarbeiten? Einen Workerthreadpool gibts hier im Forum.

Falls es untergegangen sein sollte: Imho sollte nicht der Thread abgeschossen werden (geht nicht, nur schlafenlegen geht), sondern die Connection. Und das sollte FB drauf haben. Oder Du lässt dir dir PID von der Connection geben (oder wie auch immer das bei FB heißt) und killst Du dann (wenn das bei FB geht).