Hallo!

Ich benutze Apache 2.0 + PHP 5 + MySQL 5.0 und die Funktionen von mysqli.

Mein Problem: Ich möchte Transaktionen über den Webserver verwenden. Wenn ich über den Browser Transaktionen starte, bleiben die Tabellen aber nicht gesperrt bis ein "COMMIT" kommt, sondern werden gleich ausgeführt (AUTOCOMMIT ist ausgeschalten).
Transaktionen die ich über MySQL- Control Center machen funktionieren wie gewünscht.

Frage: Kann die Konfiguration von Apache oder PHP der Grund sein?

Mister Ad

Also ich hab mal eine vorläufige Lösung gefunden für alle dies interessiert:

wenn ich die Bibliothek mysql statt mysqli verwende, dann funktionieren Transaktionen über eine persistente Datenbankverbindung mit mysql_pconnect().

Lt. Dokumentation ist eigentlich die erweiterte Bibilothek mysqli für Funktionen von InnoDB-Tabellen besser geeignet, ich kann damit allerdings trotzdem keine Transaktionen durchführen...

Zur Erklärung: ich suche keine Transaktionen während der Abarbeitung eines PHP-Scripts sondern zwischen zwei gesonderten Aufrufen.

zB:
Laden eines Datensatzes in ein Formular zur Bearbeitung (Start einer Transaktion)
Ändern der Daten
Abschicken der Daten (UPDATE und COMMIT)

kennt wer noch einen anderen Weg als pconnect? Ich hab meine Scripts jetzt schon vollständig auf mysqli umgebaut und möchte das nicht nochmals tun, außerdem bin ich mir noch nicht sicher wie ich die gestartete Transaktion von pconnect am MySQL-Server sinnvoll beenden kann.

mkl0815

ich denke nicht, das es ohne pconnect funktionieren wird. bei einem pconnect behält das php-modul die db-verbindung auch zwischen den scriptaufrufen und verwendet die spezifische verbindung wieder, wenn ein erneutes pconnect mit den gleichen verbindungsdaten gemacht wird. verwendest du connect, wird bei jedem scriptaufruf eine neue verbindung aufgebaut und bei scriptende wieder abgebaut. ein verbindungsabbau ohne commit wird vom dbms aber als "rollback" interpretiert.


allerdings kannst du bei parallelen zugriffen von mehreren (web)clients probleme mit dem pconnect bekommen, da sich alle scripte die gleich verbindung teilen und somit auch alle in der gleichen transaktion laufen. wenn eines der scripte ein commit macht, trifft das die gesamte transaktion.

mario.

__________________
Problems with Windows : REBOOT
Problems with Linux : BE ROOT

mkl0815

wie bereits in vorherigen post beschrieben, macht dieser ansatz probleme bei parallelen zugriffen von mehreren clients.

warum muss denn nach dem laden der daten aus der db bereits die transaktion gestartet werden? es reicht doch nur die "schreibenden" zugriffe, also beim wiedereintragen der daten in die db, in einer transaktion zu kapseln.

mario.

__________________
Problems with Windows : REBOOT
Problems with Linux : BE ROOT

Finde ich lesenwert:
http://de2.php.net/manual/en/functio...l-pconnect.phpWenn Du per-user Transaktionen über mehr als einen request brauchst, schau mal, ob Du die Daten sinnvoll in sessions aufheben kannst und die DB-Transaktion erst mit der Verarbeitung des letzten requests erstellst ...und dort auch beendest.
Ganz so einfach ist es meistens nicht, aber etwas Gehirnschmalz wert

Nach dem was ich darüber alles gelesen habe, sollte man eigentlich nie pconnect() verwenden. Der Perfomancevorteil ist nicht sehr groß zu einem Standard connect() (das bei gleichen Verbindungsparametern von zwei Aufrufen ja auch keine völlig neue Verbindung aufbaut - das geschieht erst, wenn man das connect() mit einem weiteren Parameter aufruft).

Vielleicht ist das Problem das autocommit. schalte es vor dem START TRANSACTION doch mal mit 'SET AUTOCOMMIT=0' aus.

Vielleicht gehts dann so.

Transaktionen haben ja 2 Vorteile. Erstens ist eine vollständige Speicherung eines bearbeiteten Datensatzes gesichert, nicht nur eines Teils (zB bei mehreren SQL-Statements hintereinander), zweitens funktioniert das gleichzeitige Arbeiten von mehreren Usern an einer Tabelle besser, weil wenn einer an einem Datensatz zu arbeiten beginnt, kann kein anderer daran arbeiten, bzw. er sieht gleich das an dem Datensatz geändert wird, und die Änderungen werden gespeichert.

Es kann immer nur eine Änderung geben, dann kommt die nächste. Ohne Transaktion läd sich der erste User den Datensatz, wenn ein anderer inzwischen eine Änderung macht, hat der erste nicht die aktuellen Daten, und wenn er seine Änderung abschickt, wird die Änderung vom 2.User einfach überschrieben. Weder der 1.User noch der 2. wissen danach was sie geändert haben und ob ihr Änderung auch angekommen ist.

Bei Transaktionen startet der 1.User seine Bearbeitung, der 2.User sieht, dass der Datensatz bearbeitet wird und kann nichts ändern. Wenn der 1.User fertig ist, sieht der 2.User die aktuellen Daten und kann immer noch entscheiden ob er was ändern muß oder nicht.

Das ist wie mit Excel. Da kann man auch gleichzeitig an einer Arbeitsmappe arbeiten, aber wenn man speichert überschreibt man die Änderungen des 2.Users ohne zu wissen, was der geändert hat.

Transaktionen ermöglichen ein korrdiniertes Zusammenarbeiten, ohne Transaktion wirds sehr chaotisch...