Tach!

Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen?

Wenn du mir sagst, wo die Verständnisprobleme liegen, kann ich nachzulegen versuchen.

Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt.

Ja, man kann es ohne Not andersherum schreiben, so dass die Berechtigung erst bei erfolgreicher Autorisierung vergeben wird. Deswegen stufe ich das Beispiel als nicht weiter relevant ein.

Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar.

Keine Daten im GET zu ändern löst das Problem. Anmeldungen erfolgen mit POST. Berechtigungsrelevante Session-Daten schreibt man also auch damit.

Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung.

Ja, wenn man sich dabei auf Datenbanktransaktionen beschränkt.

Schreibt man selbst Dateien, und hat einen solchen Anspruch, muss man etwas ähnliches entwerfen. Wird sicher nicht ganz einfach in einer konkurrierenden Multiuser-Umgebung.

Wird bei Skriptabbruch mitten im einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch?

Beschränkt auf Datenbank-Transaktionen: Die Änderungen erfolgen meines Wissens nicht direkt im Datenbestand. Wenn die Client-Session ohne Commit beendet wird, auch bei Timeout, dann werden die Änderungen verworfen und nicht in die Tabellen eingetragen. Der Rollback wird bei Abbruch also implizit ausgeführt.

Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist.

Bezogen auf einen selbst erstellten Transaktionsmechanismus: Ja, aber das ist ein anderes Thema.

dedlfix.