nicht angemeldet
Hello,
Ein Vorgang in einem Client-Server-Wechselspiel kann aus beliebig vielen Request-Response-Paaren bestehen. Solange er nicht abgeschlossen ist, darf keine zweite Instanz des Vorganges unkontrolliert auf die Daten zugreifen.
Genau das hat setckl geschrieben, da er explizit auf Filelocking hingewiesen hat. Mich deucht, du denkst komplizierter, als es hier nötig ist :)
Nein, das hat er nicht geschrieben.
Und mich dünkt, dass Du "Vorgangsbearbeitung" und "Einzelrequest" durcheinanderbringst.
Das Sperren des Session-Files während des Requests reicht als Hilfsmittel gegen "Reentranz im HTTP" nicht aus. Da muss man den ganzen Vorgang absichern.
Außerdem muss ein Session-File auch gar nicht unbedingt vollständig gesperrt werden während eines Requests, sondern es würde reichen, es nur von Beginn der Lese- bis Ende der Schreiboperation zu sperren.
Wie man mit den Daten zu einem "Formular" innerhalb einer Session umgeht, liegt eben daran, ob man Reentranz zulassen will (also paralleles Abarbeiten gleichartiger Vorgänge) oder ob man sie zu verhindern versucht (Bsp.: Jeder Client darf nur einen Kunden zur gleichen Zeit bearbeiten...). Dann muss man durch Conflict-Counter das konkurrierende Verhalten abfangen und kann dann entscheiden, ob der Nachfolgeprozess (Vorgang) den Vorgänger ablösen soll (und der Vorgänger damit stirbt) oder ob man die Bearbeitung ablehnen will.
Leider weiß der Nachfolger nie, ob der Vorgänger noch lebt. Die Übernahme der Kontrolle durch den Nachfolger ist daher Standard. (Hinweis erfolgt natürlich vorher). Sollte der Vorgänger dann doch noch gelebt haben und nochmals zugreifen, erhält er eine Nachricht, dass der Vorgang bereits durch einen Nachfolger (fertig) bearbeitet wurde - uns tschüss.
(Da mein Artikel hierzu aber immer noch nicht fertig ist, kann ich auch nicht darauf verweisen)
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Struppi