Datenbank Verbindungsabbruch - Prinzipfrage

[haentschman]

Moin...:P

Ich hätte da gern mal ein Problem...8-)

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. :roll: 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. :roll:
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]

:P 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. :wink: 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...:P

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... :thumb:
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 :wink:) war das nicht von Erfolg gekrönt.

[RSF]

Nur mal so als Idee.
In regelmäßigen Abständen ein Ping an den DB-Server senden ob aktuelle Verbindung noch aktiv ist?

[IBExpert]

muss gar kein ping sein, wir holen uns einfach gerne mal den current_timestamp vom firebird server, wenn der kommt ist alles wunderbar.

Das Blöde an der ganzen Geschichte: Es ist aber nicht immer steuerbar. Wir hatten schon Probleme beim Kunden, wo der eigetragene DNS Server
extrem lahm geantwortet hat. Aus dem Grunde sind wir da auf feste IP Adressen umgestiegen. Löste aber auch nicht alle Probleme, denn
bei dem Kunden gab es leider auch 2 Standorte auf 2 Seiten einer Straße und kein direktes Netzwerkkabel. Aus Vereinfachungsgründen
hatte man dann eben eine WLAN Bridge dazwischen gehängt, die auch recht gut funktionierte über ca. 50 m.

Die Firebird Anwendungen auf der anderen Seite waren aber leider schon ein wenig träger, das konnte man aber mit den Ping Zeiten
auch nachvollziehen, denn da war nichts mehr mit 0 ms wie im eigenen Netz, sondern je nach Lust und Laune 1-5ms ....

Komplett zusammengebrochen ist das Netz dann mal, als es extrem geschneit hat. Auch bei starken Gewitterregen leidet die Empfangsqualität
scheinbar erheblich. Das äußerte sich leider auch nicht in sofortigen Verbindungsabbrüchen, sondern manchmal passierte sekundenlang
nichts und dann ging es wieder los.

Den gleichen Effekt kenn ich von einem anderen Kunden, der eine Fat Client Windows Anwendung mit Firebird Connection auf seinen Gabelstaplern
betreibt. In einem Bereich in der Halle ist trotz direkter Nähe eine Accesspoints kein zuverlässiger WLAN Empfang. Sobald das Staplerterminal
da eine Verbindung versucht hat, steht aus der Sicht des Terminals die WLAN Verbindung und kommt auch nicht mehr ins Netz, wenn der woanders
hin fährt.

Die haben schon alles mögliche ausgetauscht und deren Systemhaus stand schon mehrfach am Rande des Wahnsinns, hat aber alles nichts
gebracht. Wenn das Ding hängt, musste es neu gestartet werden ... Die Firebird Anwendung da drauf bekam vom WLAN Protokoll weder
einen Fehler noch sonst irgendwas, bekam also keine Exception, auf die man hätte reagieren können. Ob das nun am WLAN, am AP, am Terminal
oder an sonstwas liegt, ist nicht klar. Lösung beim Kunden war einfach: Da stehen jetzt die Regale so, das da kein Stapler mehr hinfahren
kann. und der betroffenen Bereich wird für andere Sachen benutzt.

[IBExpert]

Zitat:

Zitat von haentschman (Beitrag 1325148)

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 :wink:) war das nicht von Erfolg gekrönt.

ich befürchte mal das du bei Netzwerkkabel abziehen wunderbar mit Connectionlost arbeiten kannst, wenn der Effekt aber ähnlich dem gerade geschilderten ist, dann leider nicht, weil du noch gar kein connectionlost hast und je nach Netzwerkinfrakstruktur den auch gar nicht bekommen wirst

[haentschman]

Zitat:

weil du noch gar kein connectionlost hast

...Das vermute ich auch. Ich werde mich nochmal intensiv damit beschäftigen und werde berichten. Mir würde es ja reichen das die Anwendung Application.Terminate veranstaltet. Ich möchte nur nicht das der User den Taskmanager bemühen muß. Denn das ist immer peinlich... :roll:

[Dejan Vu]

Falls der Event bei einem TCP-Verbindungsabbruch gefeuert wird, bringt er wirklich nichts. Das Problem ist meistens, das die Verbindung nicht abgebrochen wurde, aber trotzdem nichts durch komme. Daher heartbeat, Keep alive etc.

A sendet alle X Sekunden ein 'Hallo' and B. B antwortet sofort mit 'Huhu'.
A wartet nach dem eigenen 'Hallo' maximal X Sekunden bis zum Huhu. Kommt es nicht, wird die Verbindung geschlossen.
Wenn B nicht alle X*f (f>1, z.B. 1.2) Sekunden ein "Hallo" bekommt, wird die Verbindung geschlossen.

Der Client (einer von beiden ist ja logischerweise der Client) baut die Verbindung dann wieder auf.

B muss nur 'X' kennen, also quasi den Timeout.

Bei einer SQL-Connection nehmen wir auch ein 'SELECT 1' oder den timestamp, wie Holger erwähnt hat und kicken die Verbindung bei einem Timeout. D.h. wir haben eine ständig aktive Connection.

[HolgerX]

Hmm..

Bei einigen unserer Kunden gibt es auch (jede Nacht) einen ConnectionLost...

Dies hat aber damit zu tun, das diese Kunden partu den SQL-Server in eine VM installiert haben und meinen pünktlich um 23:00 Uhr einen SnapShot von der VM ziehen zu müssen.

Dies führt beim Aushängen des SnapShots zur Sicherung zu einem kompletten NetzwerkCut, der zwischen Sekunden bis hin zu Minuten dauert.

Somit muss unserer (alte) Applikation jeden morgen neu gestartet werden, da die Connection in der Nacht gekickt wurde.

Dumm nur, das die mitunter 24h / 7 Tage die Woche arbeiten.. ;)

(Dieses Problem ist übrigens ein bei VMWare bekanntes Problem, wobei es angeblich gelöst sein soll ;) )

[IBExpert]

Zitat:

Zitat von HolgerX (Beitrag 1325158)

Dies hat aber damit zu tun, das diese Kunden partu den SQL-Server in eine VM installiert haben und meinen pünktlich um 23:00 Uhr einen SnapShot von der VM ziehen zu müssen.

Diese VM Fetischisten kenne ich auch. Ist immer lustig denen mal zu erklären, das deren sogenannte Sicherungsstrategie eher gefährlich ist als hilfreich. Der VM Snapshot hat eine ähnliche Funktion bei Firebird wie Forced writes zu deaktivieren. Das was gerade im Speicher ist und auf der Platte geändert wurde wird gesichert. Ob das zur careful write schreibreihenfolge von Firebird passt ist egal. Wenn nun beim Snapshot irgendwas schief läuft (und ja, auch das ist nur software, die ggf mal auf volle oder defekte Platten trifft und dann nicht weitermachen kann), ist es gar nicht mal so unwahrscheinlich, das die gesicherte VM nicht 100% sauber ist.

Wenn das die einzige Strategie ist, dann herzlichen Glückwunsch wenn es knallt. Wir bekommen ja aus verschiedenen Umgebungen Firebird Datenbanken zur Reparatur, vor kurzem war ein dabei, bei der die ersten ca 60% der Datei auch sauber gefüllt war, der Rest waren leider binäre Nullen. Leider zeigten diverse Pointer in diesen Bereich, unter anderem Teile der Transaktionsinventory Page. Nach kurzer Analyse war klar: Keine Reparatur möglich (Wenn bei einem Auto der Motor ausgebaut ist, kann die Werkstatt mit der Meldung, das Auto springt nicht an, auch nicht umgehend das Problem beheben, aber immerhin schnell ein Ergebnis melden).

Irgendwie haben die meisten Admins im Umfeld von Virtualisierung schon religiösen Charakter, wer dann Jehova sagt (oder VM sind nicht immer die optimale Lösung), wird gesteinigt. Gerade Firebird Server selbst zu sichern ist ziemlicher mumpitz, neben den Datenbanken ändert sich da hoffentlich fast nie was, wenn die dedicated sind. Warum also jeden Tag sichern? Die Datenbanken sollten eher noch öfter gesichert werden, ob stündlich durch Shadows oder in Realtime per Replikation, da steckt die Arbeit am Ende drin.

Kleiner Tip: Einfach mal in einem unscheinbaren Bereich der Datenbankdatei mit einem Hex Editor die DB bewusst beschädigen und dann abwarten, ob der Kunde mit seiner Strategie das merkt oder tagelang eine kaputte DB absichert, die unbrauchbar ist. Solche Diskussionen wecken viele Schlaumeier oder zumindest deren Vorgesetzte oft auf.

[hstreicher]

@HolgerX
wir verwenden Shadowprotect mit VMWare und ziehen stündlich incrementelle Snapshots auch vom DB Server und haben keine Verbindungsabbrüche

[Sir Rufo]

Zitat:

Zitat von hstreicher (Beitrag 1325214)

@HolgerX
wir verwenden Shadowprotect mit VMWare und ziehen stündlich incrementelle Snapshots auch vom DB Server und haben keine Verbindungsabbrüche

Es kommt wohl auch darauf an, was man von VMware da einsetzt. Es gibt da durchaus mehr als nur VMware Player oder VMware Workstation und die sind nicht einfach nur teurer :)

[mkinzler]

Wenn aber Virtualisierung richtig eingesetzt werden soll, kommt man aus meiner Sicht nicht um bare metal Lösungen wie VMWare esx(i) o.ä. herum.

[HolgerX]

Auf die beim Kunden eingesetzte VMWare haben wir keinen Einfluss..

Sollte aber ESX sein, da es sich um eine Cluster-Farm für mehrere Standorte handelt..

Ob diese Shadowprotect einsetzen kann ich nicht sagen, nur das dies ach andere VM-Server im Haus betraf (mit anderer Software) und bereits bei VMWare eskaliert und bekannt war (~ 08/2015) und diese an der einer Lösung suchten und für 09/2015 zugesagt hatten.

Leider habe ich keine Rückmeldung seitens des Kunden bekommen.

Ich bin auch kein VM Spezialist.. ;)