funktion in haupthtread vom subthread aus starten

[Elvis]

Hallo,

ich habe folgendes Szenario. (XB 1.9 SL1)
Beim starten des Programm wird ja immer die dbesys function gelaufen.
Dort stelle ich eine Verbindung zum Datenbankserver her und habe ein globales DacSession objekt.
Nun habe ich ein Multihtread programm (in diesem Fall xb2.net) und ich kann diese DacSession in jeden Subthread einwandfrei verwenden.

In jeden Thread öffne ich brav die Datenbanken, das ist kein Problem.
Jetzt passiert folgendes die DacSession wird beendet, bzw. die Verbindung zum Datenbankserver wird unterbrochen, (Das ist kein Problem das auftaucht ich nehme es mal an da es passieren kann)

Nun frage ich vor dem öffnen der Datenbanken ab, ob die Verbindung zum Datenbankserver noch steht.

Wenn dieses wie in unserer Annahme nicht der Fall ist, wie stelle ich die Verbindung wieder her?

Die function zum Verbinden aus dem dbesys kann ich aufrufen aber ich habe die Befürchtung, weil ich es nicht im Hauptthread starte das es nicht für alle anderen threads zur Verfügung steht.

Falls ich die funtion vom Hauptthread us starten müsste, wie würdet ihr das machen.
Ich habe eine public variable genommen und diese frage ich in der do while Schleife des Main ab, ob diese true ist. Falls ja soll er die function für die Datenbankverbindung starten.
Die Variable wird verändert aber irgendwie wird die function nicht ausgeführt.

Vielen Dank für Eure Hilfe

Rene

[brandelh]

Eigentlich sollten Threads voneinander unabhängig sein, wenn ich das richtig sehe blockiert doch ein Thread das DAC Objekt und die anderen sehen in die Röhre ...
Was spricht dagegen wenn jeder Thread sein eigenes DAC Objekt hat ?

[Elvis]

Hallo Hubert,

das Programm funtioniert ja wunderbar mit einem Dacsession Objekt für mehrere Threads.
Die Frage ist wenn die Verbindung abbricht, wie bekomme ich Sie wieder gestartet, bzw. wie sage ich dem Hauptthread das er die Verbindung wieder herstellen soll?

Gruß

Rene

[brandelh]

Wenn es "wunderbar" funktionieren würde, hättest du die Frage hier nicht gestellt
Ich habe mir vor ewigen Zeiten angewöhnt alle Funktionen / Prozeduren die sich auf Dateien beziehen so zu schreiben, dass am Anfang alle Zustände gespeichert und danach wieder hergestellt werden.
Dennoch kann man vor "Nebenwirkungen" nur sicher sein, wenn man die Dateien in der Funktion selbst öffnet (OK, Satzsperren und EXCLUSIVE können immer noch stören).

Bei mehreren Threads sind die Dateizugriffe gegenseitig versteckt (jeder hat seinen eigenen Workspace), damit keine Nebeneffekte auftreten.

Wenn du also dein DAC Objekt wiederverwendest (anstatt jeweils ein neues zu erzeugen), dann darfst du es in den Threads keinesfalls killen !
Natürlich könnte man wohl irgendwie in einer Schleife prüfen "bin ich noch am Leben", aber das wäre vom Aufwand für den Rechner invergleichlich höher als es richtig zu machen

Ich habe eine Grundregel: Wenn eine Funktion eine eigene Datei aufmacht, macht sie diese wieder zu. Wenn eine Funktion nur Daten in einer DBF ändert, die sie nicht geöffnet hat, dann hat sie diese wieder in den Ausgangszustand (Selectbereich, Satznummer) zurückzusetzen, aber keinesfalls zu schließen.

Einzige Ausnahmen sind Funktionen die genau zum einheitlichen Öffnen-/Schließen der Datei gedacht sind.

Kürzer: Kein CLOSE ... oder DBCloseAll() am Ende des Threads ... wobei sich dieses eigentlich sowieso nur auf die Workspäce des Threads auswirken dürfte ...

[Tom]

Hallo, Elvis.

Es gibt zwei Möglichkeiten, um mit DAC-Verbindungen in Multithreadumgebungen umzugehen:

1. Es wird im Hauptthread eine Session initialisiert und an die anderen Threads weitergereicht. Im Thread wird mit oSession:SetDefault() dafür gesorgt, dass diese Session verwendet wird. Vorteil: Simples Session-Management. Nachteil: Nur eine Verbindung für alle Threads. Gibt es mit dieser Probleme, sind alle Threads tot.

2. Je Thread wird eine Session geöffnet und verwaltet. Das erreicht man, indem die Funktion, die auch im Hauptthread Sessions erzeugt, entsprechend von den Subthreads aufgerufen wird (beispielsweise oSession := MyNewSession()). Vorteil: Je Thread gibt es eine Verbindung. Nachteile: Keine. Bei Beendigung der Threadfunktionen sollte ein Disconnect erfolgen, sicherheitshalber kann das Sessionobjekt anschließend noch genilt werden.

Ob eine Session tatsächlich verwendet wird bzw. eine aktive Verbindung zum Server bereitstellt, kann über IsConnected() abgefragt werden, aber sehr wahrscheinlich wird man das im Fehlerfall nie zum richtigen Zeitpunkt tun. Ich habe mir schon viele Gedanken darüber gemacht, wie man auf Verbindungsfehler reagieren kann, bin aber bislang zu keiner vernünftigen Lösung gekommen. Allerdings sind sie auch, wenn eine vernünftige Konfiguration vorliegt, äußerst selten. Mit der ADS beispielsweise viel, viel seltener als "handelsübliche" Dateiprobleme.

[Elvis]

ich habe mein Problem vielleicht falsch geschildert.

Ich spreche nicht von einem Programmfehler.
Ich spreche von einer mutwilligen trennen der Verbindung. Also ich gehe zum Datenbankserver und schließe von dort aus die Verbindung des Clients oder der Datenbankserver wird heruntergefahren. Nur für diesen seltenen fall.

Gestern habe ich ein wenig getestet und herausgefunden das DacSession:isconnected() , weiterhin true zurückgibt wenn ich diese mutwillge Trennung mache.
Da meine weiteren Programmschritte darauf aufbauen zu wissen ob die Verbindung steht oder nicht ist das wohl eher das Primäre Problem.
Keine Ahnunung warum er das macht.

Rene

[Elvis]

Hallo Tom,

hast Du eine Idee warum isconnected() true zurückgibt wenn ich die Verbindung mutwillg trenne? Wir verwenden ads.

Gruß

Rene

[Tom]

Nun frage ich vor dem öffnen der Datenbanken ab, ob die Verbindung zum Datenbankserver noch steht.

Das ist eigentlich Quatsch, weil Du genau genommen bei jeder Operation auf Tabellen (Navigation, Feldzugriffe, Suche usw.) prüfen müsstest, ob die Verbindung noch besteht. Wenn es die Möglichkeit gibt, dass eine Verbindung mittendrin abbricht, kann das schließlich jederzeit passieren - und nicht nur kurz vor dem Öffnen von Tabellen. Entscheidend ist, dass man prüft, ob die Verbindung zustande kam, nachdem sie etabliert wurde. Alles andere wäre eine Fehlersituation, der man schwerlich sinnvoll in der App begegnen kann. Die ErrorSys kann darauf reagieren, aber vermutlich nicht produktiv.

Mich irritiert Deine Wortwahl auch etwas. Es gibt keine Funktionen "im Hauptthread" oder "im Subthread". Es gibt Funktionen, fertig. Habe ich eine Funktion "CreateSession()", kann ich die jederzeit und von überall aufrufen (es sei denn, sie ist als "STATIC" deklariert und ich will sie aus einer anderen PRG-Datei heraus verwenden). Die Wirksamkeit bzw. Sichtbarkeit ihrer Rückgabewerte hängt davon ab, wie diese deklariert sind.

[brandelh]

Die Anwendung selbst würde (ohne ADS) irgendwann eine Meldung bekommen, dass das Laufwerk nicht mehr zur Verfügung steht.
DAS habe ich früher leider öffters gehabt als uns lieb war.
Nur diese Meldung kommt erst nach einem Timeout und wenn das OS aufgegeben hat sie wieder herzustellen.

Wie die ADS reagiert nachdem man die Kiste mal so schnell abgeschaltet hat weiß ich nicht, aber eigentlich sollte der Serverraum vor unbefugtem Zutritt gesichert sein