j4nk3y: MySQLi transaction/commit/rollback

Beitrag lesen

Tach,

Durch

$mysqli->begin_transaction();

werden alle folgenden Datenbankzugriffe zu einer "aktion" zusammengefasst und weitere bzw andere Datenbankzugriffe werden aufgeschoben bis die "aktion" abgeschloßen ist.

nenne das ganze ruhig beim korrekten Namen Transaktion statt "aktion".

Ja ich wollte es nur umschreiben, um es anders Auszudrück. Imprinzip um meinen Gedanken zu verdeutlichen.

Bzw die Datenbankverbindung mit

$mysqli->close();

beendet wird.

Sehe ich das richtig? Z.B. auch wenn a.php , b.php aufruft und dort ein

$mysqli->query();

ausgeführt wird und die Datenbankverbindung erst in b.php geschloßen wird?

Ja, solange a.php nicht komplett ausgeführt wird, findet kein implizites Ende der Transaktion statt.

HM, hier würd ich es gern genau wissen, da ich mir hier unsicher bin. Also bis a.php fertig ist oder bis b.php die Datenverbindung beendet?

Bisher ist mir auch noch nicht ganz klar was die Funktionen

$mysqli->commit();
$mysqli->rollback();

veranstalten. Wenn dort jmd eine einfach erklärung hätte, wär ich sehr dankbar.

Die Transaktion kann mit zwei verschiedenen Zuständen enden, entweder alle innerhalb der Transaktion gemachten Änderungen werden endgültig durchgeführt (commit) oder verworfen (rollback); damit kann man also sicher stellen, dass entweder alle oder keine Änderungen einer Transaktion übernommen werden und der Zustand, die Änderungen an Tabelle 1 sind erledigt aber vor den Änderungen an Tabelle 2 hat das Script abgebrochen, vermeiden.

Na das war gut erklärt, Danke. aus dem php Manual hab ich das nicht wirklich heraus gelesen.

Sagen wir ich rufe a.php auf und dieses soll meine Datenbank füllen. Je nachdem was ich eingebe "x", läuft eine Schleife "x"-mal durch, welche meine Daten in der Datenbank setzt nach dem Schema:

Daten erzeugen -> DB verbindung aufbauen -> Daten eintragen -> DB verbindung schließen

Dies kann von einigen Sekunden bis mehrere Stunden dauern.

Nun greift ein (mehrere) Benutzer auf meine Webseite zu und fragt Daten ab. Vielleicht wichtig : Nicht aus den Tabellen an den a.php "arbeitet".

Dann solltest du keine Probleme bekommen; wie genau dein DBMS (bzw. im Falle von MySQL die verwendete Storage Engine (MyISAM kennt keine Transaktionen)) bei konkurrierenden Transaktionen vorgeht, ist eine Frage der Isolation, damit z.T. Einstellungssache und soltle im Handbuch des DBMS nachlesbar sein. Grob gilt erstmal: Während eine Transaktion läuft, können andere lesende Transaktionen (auch solche, die implizit sind) die geänderten Daten der ersten Transaktion nicht sehen und schreibende Transaktionen müssen warten, bis die erste Transaktion abgeschlossen ist.

Ok dann liege ich hier ja richtig, dass ist doch schonmal ganz nice. Ja, das geht "nur" mit der InnoDB, dass weiss ich schon. Mit der Isolation werd ich mich gleich mal schlau lesen, danke.

Inwieweit können dann probleme auftreten in der abwicklung von a.php und einem script c.php welches vom Benutzer aufgerufen wird.

Ich würde es mir so vorstellen, dass a.php seine Daten erzeugt und falls, während dessen c.php vom Benutzer aufgerufen wird diese Datenbankabfrage durchgeführt wird und wenn diese beendet wurde, a.php solange mit seinem Datenbankzugriff warten muss bis c.php fertig ist.

Ist das korrekt? Wartet a.php bzw c.php auf das fertig werden des jeweils anderen? Oder könnte dort irgendwas übersprungen werden. Und inwieweit sind parallele Ausführungen von Scripten möglich?

Wenn a.php seine Transaktion vor c.php gestartet hat und beide konkurrierend auf den selben Datenbestand schreiben wollen, dann wird die Transaktion aus c.php praktisch immer warten müssen.

Was ist der selbe Datenbestand? die gleiche Datenbank oder z.b eine gleiche tabelle in der DB?

mfg
Woodfighter