Wann ist COMIT nötig?

[Lin728]

Hallo wiedermal,

bin vor kurzem über ein SQL-Tutorial gestoßen welches mich ganz schön stuztig gemachte - darin stand man müsse nach jeder Änderung ein "COMMIT" ausführen damit die Änderungen in sämtlichen Connections des DB "sichtbar" wird.
War schon ein relativ altes Tutorial, aber stimmt dies wirklich?

Ich habe derzeit einen ziemlich großen Server laufen indem viele Änderungen ohne commit erledigt werden - alerdings möcht ich das ganze relativ Cross-DB halten und wenns mit hsqldb geht heists ja noch lange nicht dass mit PostgreSQL alles funktioniert.

Danke schonmal

[quinte17]

kommt auf die db drauf an und ist einstellungssache!

habe auf einer oracle 7.3 db in meiner lehre viel spielen dürfen :D und da war der commit nach manipulation der daten schon nötig.

vor allem bei transactions interressant, wo du mehrere befehle eingibst, und dann am schluss mit commit bestätigst... somti wird dann die db von dem einen konsistenten zustand in den anderen rübergehoben.

ohne commit siehst dann nur du die änderungen lokal in deiner ansicht.

wenn du zu beispiel einen update machst, und da versehentlich im where statement einen fehler hast, dann bist du froh wenn du einen revoke fahren kannst, damit diese neuen änderungen verworfen werden (und der normale betrieb währenddessen nicht gestört wird). solltest du dann voreilig einen commit machen, dann ärgrert man sich natürlich..

greetz

[mwanaheri]

Nun, das kommt darauf an, womit du die Änderungen vornimmst. Vielfach ist bereits ein "autocommit" eingebaut. Dann wird jede Änderung automatisch "committed". Ist dem nicht so oder ist das autocommit abgeschaltet, muss am Ende jeder Transaktion ein "commit work" stehen.
Wenn eine Transaktion mehrere Tabellen betrifft, empfiehlt es sich, sie ausdrücklich in eine Transaktion zu packen
begin transaction
insert...
insert ...
delete from ...
commit work

So wird sichergestellt, dass die Transaktion entweder ganz oder gar nicht vorgenommen wird.

[Christoph]

Das Thema Transaktionen ist wichtig und sollte von jedem DB-Anwendungsentwickler verstanden sein. Ich empfehle Dir deshalb mal in Bücher zu Datenbanken unter dem Stichwort "Transaktionen" nachzuschauen.

"Autocommit" ist gefährlich, weil es bei dieser Einstellung nicht mehr möglich ist, mehrere Statements zu einer "atomaren" Transaktion zusammenzu fassen und Du dann im Fehlerfall einen inkonsistenten Zustend der Datenbank hast.

[Jasper]

bin vor kurzem über ein SQL-Tutorial gestoßen welches mich ganz schön stuztig gemachte - darin stand man müsse nach jeder Änderung ein "COMMIT" ausführen damit die Änderungen in sämtlichen Connections des DB "sichtbar" wird.
War schon ein relativ altes Tutorial, aber stimmt dies wirklich?


ja und nein. kommt ganz auf den 'isolation level' an. was du beschreibst, ist 'read committed'. das gegenstück dazu ist 'dirty read'.


-j