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

Bei Firebird geht das über die Monitoringtabellen (MON$STATEMENTS in diesem Fall)

Zitat von mkinzler:

Bei Firebird geht das über die Monitoringtabellen (MON$STATEMENTS in diesem Fall)

Kannst Du das mal etwas genauer erklären bitte?

Ist zwar schon nen bisl älter das Thema, aber ich hab auch genau den Fall,
und da hier auch nur nach den Auslösern fürs Hängen gesucht wurde, Frage ich nochmal

Ich möchte einen Thread abschießen, der nicht mehr reagiert.
Warum der hängt, soll egal sein
Z.b. es wrid im thread ne funktion aus einer DLL aufgerufen die dann in einer Schleife festhängt,
und auf die DLL hat man keinen Einfluss.

Die Wege fürs normale beenden sind mir bekannt, funktionieren aber nicht.

Was ich bisher mache:
1.FreeOnTerminate setzen, in der Hoffnung das er sich irgendwann mal beendet, im Fehlerfall.
2.Thread Normal terminieren, im Timeout Fall /Fehler
3.Neuen Thread erstellen der die Aufgabe übernimmt

Bei meiner Simulation, kommt beim beenden des Programmes der Destructor von dem Toten Thread NICHT zum tragen.

Alternativ hab ich schon nachgedacht, den Programm Zustand zu merken und Programm neuzustarten

Was mich interesstiert:
-Möglichkeit den Thread zu killen,
-TerminateThread(MSDN link), funktioniert nicht, bzw vielleicht hab ichs falsch implemtniert? S.u.

Mein ThreadTerminate das net geht:

zusammenfalten · markieren

Delphi-Quellcode:

    FWorker.Terminate;
    StartTimeout(tmpTO,'StopThread_tmpTO',3000);

    //das hier sollte man natürlcih net tun wenn FreeOnTerminate gesetzt ist...
    while not FWorker.Finished and not isTimeout(tmpTO) do
    begin
      Application.ProcessMessages;
    end;

    //FORCE KILL:
    if isTimeout(tmpTO) then
    begin
      System.SetLastError(ERROR_SUCCESS);
      iThreadExitCode:=0;
      if not GetExitCodeThread(FWorker.ThreadID,iThreadExitCode) then
      begin
        sMsg:=SysErrorMessage(GetLastError); //== 'Das Handle ist ungültig' , ist es aber nicht windows :P
        showmessage('Fehler1');
      end;


      System.SetLastError(ERROR_SUCCESS);
      bOK:=TerminateThread(FWorker.ThreadID,iThreadExitCode);
      if bOK then
        showmessage('OK');
      else
      begin
        showmessage('Fehler2')
        sMsg:=SysErrorMessage(GetLastError); //kein OS error vorhanden
      end;
    End;

Wenn z.B. ein Socket gerade hängt, bekommst du den Thread nicht gekillt bevor das Timeout kommt.

An der Stelle wäre dann ein Multiprozessmodell wie in Google Chrome sinnvoll. Das wurde ja genau aus den Gründen eingeführt um hängende oder abgestürzte Tabs zu behandeln ohne dass der Browser selbst abstürzt. Das funktioniert in anderen Browsern ja bis heute nicht richtig.

Einen solchen externen Prozess kannst du in fast allen Fällen abschießen. Es gibt allerdings auch dafür Grenzen. Manchmal kann man nicht einmal einen solchen Prozess abschießen. Diese Fälle sind aber selten.

Zitat von 4dk2:

funktioniert nicht, bzw vielleicht hab ichs falsch implemtniert?

Windows hat sehr wohl recht - Du gibst ihm die Thread Id. Die WinApi-Mehtode GetExitCodeThread möchte aber ein Handle, nicht die ID.