Was tun bei Verbindungsabbruch

[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