Erklärung COMMIT/ROLLBACK in Transaktionen

T

ThiageX

Benutzer
Beiträge
6
Hallo zusammen,

ich bin etwas verwirrt über die beiden Befehle COMMIT und ROLLBACK innerhalb von Transaktionen.

Beispiel:

START TRANSACTION;
UPDATE konto SET stand = stand - 1000 WHERE kontonr = 1700;
UPDATE konto SET stand = stand + 1000 WHERE kontonr = 1800;
COMMIT;

Wenn bei diesem Beispiel alles glatt läuft wird die Änderung mit COMMIT vollzogen. Wenn ein Fehler auftritt, wird gar nichts gemacht? Oder bräuchte ich das keine Änderung vollzogen wird, das Schlüsselwort ROLLBACK? Wenn nein, wozu benötige ich ROLLBACK überhaupt, wenn sowieso nichts geändert wird, falls ein Fehler auftritt.

Vielen Dank für eure Erklärungen!
 
Werbung:
es könnte ja sein, daß zwar alles funktioniert, aber Du dennoch die Transaktion nicht mit COMMIT abschließen willst, daß Du gemachte Änderungen zurücknehmen möchtest.
 
Mir fehlt dazu gerade das Verständnis. Wieso sollte ich denn eine Änderung vornehmen und diese dann zurücknehmen wenn keine Fehler auftreten?
 
Wenn ich oben gezeigtes Beispiel mit ROLLBACK abschließe, dann kann ich sozusagen testen, ob die Befehle korrekt waren und es werden keine Änderungen vollzogen?
 
jepp.

Je nach Datenbank kannst Du auch DDL-Befehle wie CREATE TABLE, ALTER TABLE etc. in Transaktionen machen. Können aber nur bessere Datenbanken. Manche machen an der Stelle, wenn also ein Mix von DML und DDL auftritt, bei DDL automatisch ein COMMIT.
Für Upgrade-Prozeduren, wo vielleicht Daten eingefügt und Tabellen via ALTER TABLE verändert werden unnd dann wieder Daten eingefügt werden ist das dann, ähm, unangenehm.
 
ThiageX schrieb:
Beispiel:

START TRANSACTION;
UPDATE konto SET stand = stand - 1000 WHERE kontonr = 1700;
UPDATE konto SET stand = stand + 1000 WHERE kontonr = 1800;
COMMIT;

Wenn bei diesem Beispiel alles glatt läuft wird die Änderung mit COMMIT vollzogen. Wenn ein Fehler auftritt, wird gar nichts gemacht?
Zum Vergrößern anklicken....
Wenn ein Fehler auftritt, bricht SQL sofort ab, es kommt nicht bis zum Commit, auch nicht, wenn der Fehler im letzten Befehl vor dem Commit geschieht. Du brauchst nichts zu machen. (Auch) die fehlerlosen Datenänderungen der aktuellen Transaktion werden nicht persistiert. Der (Daten)Zustand ist dann der vor "Start Transaction".

Das Verhalten im Nicht-Fehler-Fall (Normalfall) wird durch die meisten DB Clients "verschleiert", weil sie per Default mit Autocommit arbeiten.

Fehler sind ärgerlich, aber ihre Behandlung durch die DB ist ein (unterschätztes) Kernmerkmal eine ACID DB Engine. Wenn Du eine DB nicht als "dummen Datenspeicher" verwendest, fängst Du eigentlich erst an, ihre vielen Vorteile zu nutzen, sonst reicht oft schon eine Textdatei oder meinetwegen ein Tool mit dem mehrere an einer Textdatei schreiben können.
Vom einfachsten Fall "Typverletzung" bis hin zur Verletzung komplexer ((Foreign-) Key-) Constraints, die DB garantiert(!), dass alle "Spielregeln" für den gespeicherten Datenbestand eingehalten werden. Das ist ein mächtiges Werkzeug und m.E. der primäre Existenzgrund solcher Systeme.

Das Verständnis dieses Mechanismus und auch der Eigenarten bestimmter Implementierungen (verschiedene Hersteller) ist recht wichtig.
akretschmer hat schon ein sehr gutes Beispiel genannt.
 
Werbung:
Ich dachte, du würdest Deine Aussage vielleicht noch erläutern. Deswegen hatte ich gefragt, ist ja weniger komisch als üblich in einem Forum.

Was mir für den TE oder andere wichtig war:
Viele sind sich nicht bewusst, dass das Standardverhalten Autocommit nur Standard, aber nicht Schicksal ist. Auch wenn > 90 % der Tools initial so daher kommen.

Der Benefit von Transaktionsverhalten des Servers bzw. die Möglichkeiten von expliziter Transaktionskontrolle gehen dabei meist unter. Im schlechtesten Fall, bis es einem mal in die Hacken läuft. Ich habe es immer gerne genutzt, um Supportfälle zu prüfen oder in der Entwicklung verschiedene Varianten zu testen. Ein Rollback und alles ist auf 0 (im Fehlerfall sowieso), egal wieviel vorher geändert und vermurkst wurde, nächster Test.
 
Zurück
Oben