Datenbank Verbindungsabbruch - Prinzipfrage

[haentschman]

Moin...

Ich hätte da gern mal ein Problem...

Ich beziehe mich mal nur auf IBDAC. Das ganze kann mit anderen Komponenten sich ganz anders verhalten.

IST:
* DB Connection im Mainthread
Wenn während einer bestehenden Connection die Verbindung abbricht (Putze über Netzwerkkabel gestolpert) bekommt die Anwendung das, in der Regel, nicht mit. Beim nächten Zugriff auf die DB hängt mir immer die Anwendung und schmeißt noch nicht mal eine Exception. Dann würde nämlich ein MessageDialog aufgehen und die Anwendung, nach OK, sicherheitshalber beendet. Oder der Mainthread hängt schon vorher fest...

SOLL:
Auswertung des Verbindungsabbruches und Neuconnection.

Wie händelt ihr so etwas?
In einer anderen Anwendung habe ich die DB Verbindungen in Threads. Dort beende ich, im Fehlerfalle, den jeweiligen Thread von außen und starte ihn nach einer Zeit X neu. Damit wird die DB Verbindung "abgewürgt" und neu aufgebaut. Das funktioniert gut. Wie aber wenn es im Mainthread abläuft?

PS:
IBDAC hat eine Property (LocalFailOver in Verbindung mit OnConnectionLost.) die bei Verbindungsabbrüchen das entsprechend händeln soll. Ich habe es nicht stabil hinbekommen.
Die Tipps wie hier z.B. http://www.delphipraxis.net/163086-f...abbrueche.html erwähnt habe ich auch durch.


Danke für Info´s.

[jobo]

Also wir haben eine prima Putzfrau, ich kenne solche Probleme nicht.


Ernst: Wenn es die Putzfrau war, macht das von Dir angestrebte Verfahren Sinn? Steckt die das Kabel gleich immer wieder rein?
Worauf ich hinaus will. Falls es um eine instabile (WAN) Verbindung geht, muss man da vielleicht anders ran, als der Umgang mit Stecker raus, Server down, ... denn hier nützt ein auto reconnect kurzfristig wahrscheinlich gar nichts.

[haentschman]

Das mit der Putzfrau ist weit hergeholt...

Im speziellen habe ich auf meiner Maschine den Firebird laufen und verbinde mich nicht über localhost sondern über den Servernamen. Gleichzeitig besteht ein VPN (nicht aus meiner Anwendung heraus) nach extern. Bei der allnächtlichen Zwangstrennung des DSL wird nicht nur das VPN getrennt und wieder neu aufgebaut, sondern auch die Datenbankverbindung der laufenden Anwendung zum Firebird Server wird, wahrscheinlich kurzzeitig, gekappt. Warum das so ist kann ich nicht sagen. Dieses verursacht diesen Effekt. Ich würde gern solche Eventualitäten sauber behandeln. Wenn ich die Anwendung über Nacht laufen lasse kann ich sie beim nächsten Benutzen einfach nur abschießen. Das gefällt mir mal gar nicht.

[IBExpert]

Eines der zentralen Punkte ist es dabei, ob du mit Datatsource/Dataset arbeitest (so wie das ca. 95% aller Delphianer machen) oder die gerade gebrauchten Daten in eigenen Strukturen/Objekten/Listen im Client speicherst (so wie unter anderem wir das mittlerweile nur noch machen). Das zweite Verfahren ist bei uns sogar immun gegen das Umschalten auf einen zweiten replizierten Server, falls der erste nicht mehr erreichbar ist. Bei Datasource/Dataset musst du ziemlich viel wieder herstellen, damit der Anwender wieder annähernd das gleiche sieht wie vorher. Die DS/DS Komponenten verlieren beim Verbindungsabbruch nämlich so ziemlich alles, was die brauchen, um wieder sinnvoll als zu arbeiten (TField Objekte, Transaction bzw. Query Handles, Bookmarks bzw Cursorposition, etc).

Einige Komponenten für Datasource/Dataset Operationen können das zwar relativ gut vereinfachen, aber perfekt hat das aus meiner Sicht keine einzige gelöst, daher auch der komplette Umstieg weg davon bei uns. Wenn ich was von der Datenbank will, sag ich der das, wenn die dann nicht antwortet, reagier ist eben so wie ich will (u.a. umschalten auf anderen Server, lokale Storage oder was auch immer). Aber nur weil irgendjemand bei mir im Front End durch eine Datenmenge scrollt, werden noch lange keine weiteren Datensätze gefetcht. Und ganz nebenbei geschieht auch nahezu alles in extrem kurzlebigen Transaktionen.

Das löst zwar ggf. deine Probleme auf Basis Datasource/Dataset nicht, sofern du das benutzt, aber es geht ja auch in deiner Frage um Prinzip Fragen.

[Dejan Vu]

Also die Putzfrau taugt als plakatives Beispiel eigentlich. Bei mir waren das jedoch eher überintelligente Switches (Cisco!) oder ein instabiles WAN (wie bereits erwähnt). Richtfunk (in ruralen Gebieten in Madagaskar) sind auch Kandidaten für ein derartiges Szenario.

Holger hat schon Recht: In so einem Fall bringen die KlickibuntiDatasets rein gar nichts. Aber die bringen auch so nichts, weil ein instabiles WAN i.a. auch mit reduzierter Bandbreite einhergeht. Ergo kann man sich die Kundenliste nicht präventiv einladen, sondern muss mit Queries, Pagination und Objektpersistenz etc. arbeiten.

[haentschman]

Danke an alle...

Von Datasets habe ich mich schon vor längerer Zeit getrennt. In meinen Anwendungen liegen die Daten als Objekte in generischen Listen. Dazu gibt es eine Datenbankschicht als Interface die ausschließlich reines SQL absetzt...
Der Fehler tritt dann immer auf wenn das SQL abgesetzt wird. Es geht quasi nur um die Connection die wieder die Verbindung herstellen muß. Selbst das letzte Statement müßte nicht erneut ausgeführt werden.

Ich werde mal noch ein wenig mit dem OnConnectionLost Event vom IBConnection rumspielen. Das soll ja dann genau greifen. Bei den letzten Versuchen (vor 1 Jahr oder so ) war das nicht von Erfolg gekrönt.