nicht angemeldet
Hi Michael!
genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.
Eine Transaktion ist nur das Ganzes durchführbar, sie umfaßt beliebig viele SQL-Statements (auf beliebig vielen Tabellen) und endet mit "commit" oder "rollback".
Unterstützt Dein RDBMS dieses Konzept?
Ja, aber das Problem ist die Client-Server Architektur. Meines Wissens ist es nicht möglich mit PHP auf dem Server eine Transaktion zu starten, den Thread zu beenden, und bei einem Request 10 Minuten später diese Transaktion wieder aufzunehmen und zu beenden. Wenn das alles innerhalb eines Scripte wäre hätte ich auch kein Problem, nur liegt zw. dem Start und dem Ende der Transaktion das Ausfüllen von 3 HTML-Formularen und dem entsprechend der HTTP Verkehr vor und nach jedem Ausfüllen eines Formulares. Solange darf das nichts passieren. Soweit ich weiß wird die Transaktion automaisch beendet, sobald das Script welches die Transaktions gestartet hat beendet ist. Oder gibts da doch eine Möglichkeit? Das wäre natürlich genial!
Aber was wenn jetzt 2 Benutzer dieselben Daten editieren wollen? Das darf nicht sein, also muss ich mir eine Art Locking-Mechanismus überlegen.
Generationen von Datenbank-Herstellerfirmen beschäftigen sich mit diesem Problem seit mehreren Jahrzehnten.
Wer sagt dass ich es nicht mal eben besser machen kann?
*Scherz* ;-)
Dein Skript muß mir der Situation leben können, daß eine Transaktion auch scheitern kann - das ist alles. (Ob Du in diesem Falle automatisch einen retry machst oder eine Fehlermeldung ausgibst, das ist Deine Design-Entscheidung.)
Ja, und das geht wohl nur über einen Timeout. Im Prinzip bilde ich ja eine Transaktion nach wenn ich den Datensatz mit einem Flag sperre, und da HTTP Zustandslos ist brauche ich halt mal wieder diesen Timeout. Oder meinst DU dasgeht auch anders?
Viele Grüße
Andreas