Inoffizielles deutsches Xbase-Forum

Gestern bin ich auf eine Situation gestossen, die mir Probleme bereitet. Ich fordere ein Result (Livecursor) vom ADS an. Danach ist eine Reihe von Arbeiten dran und dann wird das Result wieder gschlossen. So weit so gut. Leider ist der Vorgang aber mittendrin abgebrochen worden, weil es einen Fehler im Programm gab. Der Client wurde wieder auf die index.html Seite geworfen, aber das Result war noch offen. Beim nächsten Vorgang kam dann die Meldung beim Schreiben, das der Satz noch von einem anderen User gesperrt wäre. Das ist schon blöd weil es ja immer wieder mal vorkommen kann. Wie löst man so Absturzprobleme? Irgendwie muß ja das Result wieder geschlossen werden. Der ADS hat ja seine Verbindung über xb2net noch zum Programm, was ja weiter läuft. Nur der Client im Web ist ja draußen.

Wie löst man so Absturzprobleme?

a) Dadurch, dass man solche möglicherweise kritischen Prozesse (also den, der den Fehler ausgelöst hat) in Sequenzen einbettet und im Fehlerfall entsprechend agiert.
b) Durch Timeouts auf der Serverseite.

zu b) einen Timeout gibt es, aber der greift ja nicht nach Sekunden(wäre ja auch sicherlich zu kurz gedacht). Und der User meldet sich ja sofort wieder an und kommt dann in erneut besagte Situation, weil er ja ab da auch als Fremdling gilt, der einen gesperrten Satz anpacken will. (Zumindest ist das in der Situation der Fall)
zu a) könntest Du mir da näheres zu schreiben? Ich habe im Moment keine Idee, wie Du das umsetzen würdest.

Hallo Manfred !

zu a) könntest Du mir da näheres zu schreiben? Ich habe im Moment keine Idee, wie Du das umsetzen würdest.

Indem du an allen kritischen Stellen immer auf korrekte Rückgabewerte prüfst und ist das nicht der Fall, die Connection zum ADS ordnungsgemäß schließt und die Funktion beendest.

HaPe, Manfred spricht von einem Fehler, also einem Laufzeitfehler. Im einfachsten Fall sichert man das Fehlerobjekt, bettet die gesamte Routine, in der dieser Fehler geschehen kann, in eine Sequenz, und ergänzt das Break() im ersetzten Fehlerobjekt durch das Schließen der Verbindung.
Die MsgBox soll nur verdeutlichen, dass man den Fehler auch tracken kann, selbst in einer Serversituation. "CloseConnection" ist abstrakt - hier sollte dann also die Verbindung geschlossen werden.

Hi Tom,
stimmt. Ich vergesse immer wieder, das man sowas ja auch in xb2net programmieren kann.

Ich vergesse immer wieder, das man sowas ja auch in xb2net programmieren kann.

Das ist gerade bei Serverprogrammierung ziemlich wichtig. Du hast ja keinen Benutzer, der davorsitzt, und neben der Fehlervermeidung und -analyse ist extrem wichtig, dass der Server läuft und erreichbar ist. Falls es um eine Art Server gehen sollte. Ansonsten sollte natürlich auch bei einem Frontend in der ErrorSys dafür gesorgt werden, dass ggf. offene Connections geschlossen, Semaphoren freigegeben oder gelöscht usw. werden.

naja, das Dingen dabei ist, der Server läuft weiter nur der Client wird rausgeworfen. Ich muß das alles mal ordentlich verfeinern.

Ich nehme an, der Workerthread wird einfach beendet. In Xb2.Net sind alle Serverklassen auch von Thread() abgeleitet, und im Fehlerfall beenden sie sich einfach. Falls Du das so verwendest, kannst Du das Schließen der Verbindung auch dort einbauen.

ok, das wäre das gewesen, worauf ich hier als Antwort gehofft habe. Aber leider fehlt mir da noch Wissen, wie man sowas angeht.

Hallo, Manfred -


dann schaue Dir mal die Methode :atEnd() sowie die iVar :atEnd der Thread()-Klasse an, das ist wahrscheinlich der Ansatzpunkt, den Du suchst.

Nein, es ist der :onError-Slot. Einfach da das Schließen der Connections (u.a.) reinpacken.

Hallo Tom !

HaPe, Manfred spricht von einem Fehler, also einem Laufzeitfehler.
... rettet die gesamte Routine, in der dieser Fehler geschehen kann, in eine Sequenz, und ergänzt das Break() im ersetzten Fehlerobjekt durch das Schließen der Verbindung.

Mir war nicht klar, das in Xbase++ das try/catch aus C/C++/C#/VFP/Java/Python/Matlab/PowerShell/... mittels Sequenz umgesetzt wird.
Sonst hätte ich das dazugeschrieben, weil ich try/catch in Xbase++ nicht gefunden habe.

Tom hat geschrieben: ↑Mi, 02. Mär 2022 12:12 Nein, es ist der :onError-Slot. Einfach da das Schließen der Connections (u.a.) reinpacken.

aber das result wird doch in eine Local var geschrieben. Wie komme ich dann da dran?. Und Connection wäre doch die komplette Verbindung des webServers zum SQl Server? Die will ich ja nicht schließen.

Ich arbeite mit dem ADS nicht auf diese Weise (das mache ich mit Postgre), deshalb kann ich Dir nicht genau sagen, was zu tun wäre, um die Sperrung aufzuheben, aber die Strategie wäre halt, im Fehlerfall entsprechend zu reagieren. Tatsächlich nutzen wir bei aktiver ADSDBE im Xb2.Net-Server auch eine eigene Session je Verbindung von außen (also im jeweiligen Serverthread findet ein Connect statt), die bei Beendigung und/oder im Fehlerfall geschlossen wird (während wir in der Hauptanwendung nur eine Session für alles nutzen, die an alle Threads per SetDefault sozusagen vererbt wird).

Hallo Manfred
Da du das wahrscheinlich mit AdsClass machst, du musst die Connection der SQL Verbindung schliessen, nicht die Connection zum Server als solche:

Tom schrieb:

auch eine eigene Session je Verbindung

Unbedingt.

Hi Marcus
das ist m.E. nicht das Problem. Das mache ich ja. es geht darum wenn ich nicht an das :close komme, sondern vorher der Client "stirbt"

Wie kann der Client sterben, bevor du deine Verarbeitung beendest hat
Ich mache für jeden Request die Datenbanken auf und schliesse alles wieder bevor ich die HTML Seite zurückschicke.

ganz einfach, irgendwo im Ablauf des Codes ist ein unerkannter Fehler. Dann wirft der Webserver den Client raus und er steht im Loginbildschirm, wie schon oben erklärt.

Das sind jetzt aber zwei Dinge gleichzeitig.

Es gibt einen Fehler und der Server reagiert darauf mit dem Anmeldedialog (weil der vermutlich bei "onGet" oder als "IndexFile" angegeben ist - und ein verkehrter Request reinkommt). Du kannst aber auch im Fehlerfall dem Benutzer irgendwas anzeigen ("onError" kann z.B. auch HTML senden). Das ist aber nicht die Frage, die Du oben gestellt hast. Da hast Du nach einem verbliebenen Lock gefragt, nach einer noch offenen Session.

hi HaPe,

HaPe hat geschrieben: ↑Mi, 02. Mär 2022 12:57 weil ich try/catch in Xbase++ nicht gefunden habe.

wie wäre das