nicht angemeldet
Hello,
Beispiel:
Du baust Dir eine Kundenverwaltung.
Die hat eine alphabetische Liste, in der die Kunden in Kurzform aufgelistet werden.
Jede Zeile hat einen "Bearbeiten-Button"
Dieser löst einen Request auf eine Einzeldarstellung des Kunden (in einem separaten Fenster aus)
Wenn Du nun bei mehreren Kunden dieses Fenster anforderst, dann hast Du nachher eben (sagen wir mal) drei davon auf dem Schirm.
Die polymorphen Daten müssen in Deiner Session aber auch verarbeitet werden können.
Die Unique_ID eignet sich bestens dafür.
OK, Du könntest sagen: das regel ich doch über die ID des Kunden.
Sag ich: Und was ist, wenn Du in Deinem Klick-Chaos für denselben Kunden viermal dasselbe Fenster anforderst?
Dann wird es kritisch.
Das kann dann einerseits durch einen Konfliktzähler im Datensatz abgefangen werden (also ausschließlich auf Datenbankseite, wenn man eine vernünftige zur Verfügung hat), oder eben durch ein Formular-Zertifikat.
Wenn man "DISTINCT only" für den Prozess und die Daten wählt, dann würde das ältere Zertifikat durch das neuere erledigt (noch nicht unbedingt gelöscht) und dessen Daten in der Session könnten beseitigt werden. Wenn man aber Prozesse hat, die durchaus paralleles Arbeiten mit unterschiedlichen Instanzen desselben Objektes benötigen, dann bleiben die Zertifikate eben alle gültig, bis sie erledigt sind (durch Request oder durch Timeout).
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
