Was tun bei Verbindungsabbruch

[xaromz]

Hallo,

ich habe mal eine Frage zur grundsätzlichen Strategie:
Wenn man mit Datenbanken arbeitet, kann es ja immer passieren, dass der Datenbankserver plötzlich nicht mehr erreichbar ist (Netzwerk abgeschmiert, Server abgestürzt...).
Wie ist in so einem Fall die beste Vergehensweise, wenn gerade die Ergebnisse eines Queries durchgegangen werden?

Sollte man, nachdem die Verbindung wieder steht, die Abfrage von vorne beginnen, oder in der Zeile weitermachen, wo man aufgehört hat (dann kann sich aber ja das Ergebnis schon geändert haben)?
Was macht eine Datenbank, wenn z. B. ein Insert/Update-Query nur halb ankommt? Ich hoffe doch, den Müll verwerfen, oder?

Macht Ihr vielleicht alles ganz anders? Ich bin gespannt auf Eure Methoden, mit dieser Situation umzugehen.

Gruß
xaromz

[gmc616]

Hallo xaromz,

Zitat:

Zitat von xaromz

Sollte man, nachdem die Verbindung wieder steht, die Abfrage von vorne beginnen, oder in der Zeile weitermachen, wo man aufgehört hat (dann kann sich aber ja das Ergebnis schon geändert haben)?

Ich denke die Frage hast du dir grade selbst beantwortet. :mrgreen:

Zitat:

Zitat von xaromz

Was macht eine Datenbank, wenn z. B. ein Insert/Update-Query nur halb ankommt? Ich hoffe doch, den Müll verwerfen, oder?

Eigentlich schon. Große DB's arbeiten mit den Commit/RollBack-Verfahren (heißt des so?).
Somit ist eine Transaktiontion in der DB erst gültig, wenn ein Commit gesendet wurde.
Stürzt der DB-Server mal ab, sind die Daten auf dem Stand des letzten Commits.
Bricht die DB-Verbindung weg, is es ähnlich. Das letzte Commit zählt.

Ich hoffe, ich hab nix falsches erzählt. :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von gmc616

Ich hoffe, ich hab nix falsches erzählt. :zwinker:

Dies gilt für Datenbanken die das ACID-Eigenschaften besitzt.
Dies sollte für jede "normale" SQL-Datenbank der Fall sein.

Bei Desktopdatenbanken schaut es anders aus. Hier kann sehr wohl ein Verbindungsabbruch zu einer zerschossenen DB oder ungültigen Zustand in der DB führen.

[xaromz]

Hallo,

Zitat:

Zitat von gmc616

Ich denke die Frage hast du dir grade selbst beantwortet. :mrgreen:

Schon klar :wink: , dann verändere ich meine Frage: Wenn sowas passiert, sollte man dann sämtliche schon verarbeiteten Werte verwerfen und nochmal von vorne anfangen? Bei meinem aktuellen Projekt erstelle ich für jede Tabellenzeile ein Objekt, ich müsste also alle gelesenen Objekte wieder zerstören und neu erstellen. Da ich ungefär 100 Stellen im Programm habe, wo sowas passiert, wäre ich an einer einfacheren Lösung interessiert. Aber wahrscheinlich ist es wie immer im Leben: Einfache Lösungen gibt es nicht.

Zitat:

Zitat von gmc616

Eigentlich schon. Große DB's arbeiten mit den Commit/RollBack-Verfahren (heißt des so?).

Ja, das heißt so.

Zitat:

Zitat von gmc616

Somit ist eine Transaktiontion in der DB erst gültig, wenn ein Commit gesendet wurde.
Stürzt der DB-Server mal ab, sind die Daten auf dem Stand des letzten Commits.
Bricht die DB-Verbindung weg, is es ähnlich. Das letzte Commit zählt.

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig :zwinker: .

Gruß
xaromz

[Bernhard Geyer]

Zitat:

Zitat von xaromz

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig :zwinker: .

Solche ein Query bekommt die Datenbank gar nicht mit da dies auf tieferer Ebene (vermutlich TCP oder erste Layer darüber) erkannt wird und gar nicht bis zum QueryAnalyser der DB kommen.

[RavenIV]

Zitat:

Zitat von Bernhard Geyer

Solche ein Query bekommt die Datenbank gar nicht mit da dies auf tieferer Ebene (vermutlich TCP oder erste Layer darüber) erkannt wird und gar nicht bis zum QueryAnalyser der DB kommen.

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Die Transaktionen müssen schon von der Applikation (in diesem Fall die Datenbenk-Software) verwaltet werden. Die meisten DBMS arbeiten intern auf transaktionsbasis, wovon der Anwender (deine Software) nichts mitbekommt.

[Peinhard]

Zitat:

Zitat von xaromz

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig :zwinker: .

Dann arbeitet deine Datenbank bzw die Verbindung/Sitzung mit hoher Wahrscheinlichkeit ;) im AutoCommit-Modus - jedenfalls wenn es sich um ein 'richtiges' DBMS handelt und du erfolgreich Änderungen vornehmen kannst. Das bedeutet, daß das DBMS jeden einzelnen Befehl automatisch selbst in eine Transaktion 'einkapselt'. Lies mal büschen was über Transaktionen, AutoCommit und auch implizite Transaktionen. Und so ganz 'egal' wie du eingangs erwähntest ist die DB natürlich auch nicht - Fileserver-DBs zB verhalten sich deutlich weniger 'gnädig', da kann's dann zB die beliebten 'corrupt indices' setzen.

Die Sorge, daß eine nur 'halb angekommene' Query abgearbeitet wird, ist aber schon 'im Vorfeld' unbegründet, wie Bernhard schon schrieb.

[Bernhard Geyer]

Zitat:

Zitat von RavenIV

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Dann ist es halt die Klasse/Modul welches auf TCP aufsetzt und den komplett gültige empfang von SQL-Anweisungen verwaltet. Also Layer 5 des OSI-Referenzmodells

[Peinhard]

Zitat:

Zitat von RavenIV

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Wenn der Befehl aber nur 'halb' ankommt, weil die Verbindung während seiner Übermittlung abreißt, fehlt sozusagen seine 'Terminierung'. Die Engine müßte iü ja auch 'wissen' ob da noch was kommt, oder ob's das jetzt war und sie loslegen soll/kann. Und der Stack 'weiß' zwar nicht was drin ist, aber schon, ob die Übermittlung vollständig ist. Und wenn nicht, geht der Befehl da gar nicht erst raus, sondern es wird eine (dem Szenario entsprechend nicht erfolgreiche) 'Neuverhandlung' versucht. Correct me if I'm wrong...

[RavenIV]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von RavenIV

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Dann ist es halt die Klasse/Modul welches auf TCP aufsetzt und den komplett gültige empfang von SQL-Anweisungen verwaltet. Also Layer 5 des OSI-Referenzmodells

Hast Du das OSI-Modell durchgelesen?
Es kann nicht Schicht 5 sein. Die weis noch nichts von DB-Transaktionen.
Erst Schicht 7 – Anwendungsschicht kennt das und kann das auch erst machen.

[xaromz]

Hallo,

danke für die bisherigen Informationen.

Zitat:

Zitat von Peinhard

Lies mal büschen was über Transaktionen, AutoCommit und auch implizite Transaktionen. Und so ganz 'egal' wie du eingangs erwähntest ist die DB natürlich auch nicht - Fileserver-DBs zB verhalten sich deutlich weniger 'gnädig', da kann's dann zB die beliebten 'corrupt indices' setzen.

Um die Datenbank etwas zu präzisieren: Ich schreibe gerade einen Abstraktionslayer für mehrere Datenbanken, u. a. MySQL, MSSQL, Oracle, DB2 und Firebird, da es meinem Programm egal sein soll, in welcher Datenbank die Daten liegen. Bei der Gelegenheit habe ich mir auch noch einen eigenen Server in .Net geschrieben, der Queries (eigener Dialekt) zur DB durchreicht und die Verbindung verschlüsseln kann. Dazu werde ich vermutlich demnächst noch einen Thread aufmachen und das vorstellen.

Gruß
xaromz

[RavenIV]

Zitat:

Zitat von Peinhard

Zitat:

Zitat von RavenIV

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Wenn der Befehl aber nur 'halb' ankommt, weil die Verbindung während seiner Übermittlung abreißt, fehlt sozusagen seine 'Terminierung'. Die Engine müßte iü ja auch 'wissen' ob da noch was kommt, oder ob's das jetzt war und sie loslegen soll/kann. Und der Stack 'weiß' zwar nicht was drin ist, aber schon, ob die Übermittlung vollständig ist. Und wenn nicht, geht der Befehl da gar nicht erst raus, sondern es wird eine (dem Szenario entsprechend nicht erfolgreiche) 'Neuverhandlung' versucht. Correct me if I'm wrong...

auch das ist nicht korrekt.
Jede Schicht prüft, ob ihre Anforderungen für die Übertragung gegeben sind.
Der "TCP-Schicht" ist doch wurscht, was in den Paketen drin ist. Sind die einzelnen pakete gültig, werden sie weitergegeben. Fehlt ein paket, wird es neu angefordert. Ist ein paket falsch, wird es neu angefordert.
Die nächste Schicht setzt dann die Pakete zusammen. Dies könnte die Kommunikation zweier DB-Komponenten sein. Aber auch diese Schicht weis noch nichts von Transaktionen.
Erst die letzte Schicht (eben die DBMS-Applikation) kann entscheiden, ob die
Transaktion komplett ist.

[RavenIV]

Zitat:

Zitat von xaromz

Ich schreibe gerade einen Abstraktionslayer für mehrere Datenbanken, u. a. MySQL, MSSQL, Oracle, DB2 und Firebird, da es meinem Programm egal sein soll, in welcher Datenbank die Daten liegen.

Den ZEOS-Komponenten ist es auch egal, was für eine DB angesprochen werden soll.
Kann man einstellen, ob sie zu MSSQL, MySQL, PostgreSQL oder weitere connecten sollen.

[Peinhard]

Zitat:

Zitat von RavenIV

auch das ist nicht korrekt.
Jede Schicht prüft, ob ihre Anforderungen für die Übertragung gegeben sind.
Der "TCP-Schicht" ist doch wurscht, was in den Paketen drin ist. Sind die einzelnen pakete gültig, werden sie weitergegeben. Fehlt ein paket, wird es neu angefordert. Ist ein paket falsch, wird es neu angefordert.
Die nächste Schicht setzt dann die Pakete zusammen. Dies könnte die Kommunikation zweier DB-Komponenten sein. Aber auch diese Schicht weis noch nichts von Transaktionen.
Erst die letzte Schicht (eben die DBMS-Applikation) kann entscheiden, ob die
Transaktion komplett ist.

Ob die Transaktion komplett ist ja. Die beginnt aber überhaupt erst, wenn ein gültiger und vollständig übermittelter Befehl vorliegt. Daran sind, wie Bernhard eben auch schon schrieb, im Zweifelsfall mehrere Layer beteiligt - wenn ein Paket nicht vollständig ist zB verläßt es den TCP/IP-Stack gar nicht erst, wenn ein Befehl nicht vollständig und 'terminiert' ist, eben eine höhere Schicht.

[xaromz]

Hallo,

Zitat:

Zitat von RavenIV

Den ZEOS-Komponenten ist es auch egal, was für eine DB angesprochen werden soll.
Kann man einstellen, ob sie zu MSSQL, MySQL, PostgreSQL oder weitere connecten sollen.

Ich weiß, es gibt verschiedene Komponenten, die eine Abstraktionsschicht bieten. Es gibt aber ein paar Unterschiede zu meiner Version:

• Alle Komponenten, die ich bisher angesehen habe, wollten SQL-Statements im der Datenbank entsprechenden Dialekt. Ich verwende zur Kommunikation ein anderes Format, das in den entsprechenden Dialekt umgewandelt wird.
• Meine Lösung kann die Verbindung zu jeder Datenbank verschlüsseln.
• Mein Server beinhaltet ein Rechtemanagement, kann also Anfragen daraufhin überprüfen, ob sie erlaubt sind. Dieses Management ist unabhängig von dem der Datenbank (und auch für andere Zwecke gedacht).
• Mit meiner Lösung kann man Queries objektorientiert zusammenbauen.

Du siehst also, ich erfinde das Rad nicht neu, ich baue ein anderes Rad :zwinker: .

Gruß
xaromz

[Bernhard Geyer]

Zitat:

Zitat von RavenIV

auch das ist nicht korrekt.
Jede Schicht prüft, ob ihre Anforderungen für die Übertragung gegeben sind.
Der "TCP-Schicht" ist doch wurscht, was in den Paketen drin ist. Sind die einzelnen pakete gültig, werden sie weitergegeben. Fehlt ein paket, wird es neu angefordert. Ist ein paket falsch, wird es neu angefordert.
Die nächste Schicht setzt dann die Pakete zusammen. Dies könnte die Kommunikation zweier DB-Komponenten sein. Aber auch diese Schicht weis noch nichts von Transaktionen.
Erst die letzte Schicht (eben die DBMS-Applikation) kann entscheiden, ob die
Transaktion komplett ist.

Ich glaube wir haben aneinander vorbei geredet. Ich meinte mit Schicht4/5 den Fall das bei einer SQL-Anweisung wie oben genannt:

Zitat:

Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig

diese mit Sicherheit schon auf unterer Ebene (4/5) behandelt wird da ja mit Sicherheit auf Protokoll-Ebene der Datenbank erkannt wird das hier nicht alle nötigen IP-Packete angekommen sind.

Das die Transaktionssteuerung mehr Intelligenz (höhere Ebene) erfordert ist mir klar. Mir ging es nur um diesen Fall das eine SQL-Anweisung nur halb ankommt (Z.B. auf 2 IP-Packete verteilt wovon das 2te verloren geht).

[RavenIV]

Zitat:

Zitat von Bernhard Geyer

diese mit Sicherheit schon auf unterer Ebene (4/5) behandelt wird da ja mit Sicherheit auf Protokoll-Ebene der Datenbank erkannt wird das hier nicht alle nötigen IP-Packete angekommen sind.

Die Datenbank hat keine Protokollschicht.
Die liegt im Betriebssystem verborgen.

Falls dieser Fall eintreten sollte, dass nur ein Teil der zur Query gehörenden pakete ankommen, wird dir wohl das Betriebssystem auf dem Client eine Exception werfen. Diese wird evtl von den Delphi-Komponenten für den DB-Zugriff abgefangen und weitergereicht.

[xaromz]

Hallo,

Zitat:

Zitat von RavenIV

Falls dieser Fall eintreten sollte, dass nur ein Teil der zur Query gehörenden pakete ankommen, wird dir wohl das Betriebssystem auf dem Client eine Exception werfen. Diese wird evtl von den Delphi-Komponenten für den DB-Zugriff abgefangen und weitergereicht.

Das Betriebssystem auf dem Client hat damit ja nichts zu tun. Wenn der Client die Daten abgeschickt hat, und mitten in der Übertragung schneide ich das Netzwerkkabel durch, bekommt der Server möglicherweise nur ein paar IP-Pakete. Klar sagt der Client dann, dass die Verbindung unterbrochen wurde, aber die Frage ist ja, was kommt bei der Datenbank an:

• eine korrupte Abfrage
• gar nichts
• eine Notification
• ...

Und wie reagiert die Datenbank, sollte eine korrupte Abfrage ankommen? Ich denke, sie verwirft diese.

Gruß
xaromz