nicht angemeldet
Moin!
Die UNIQUE-ID des Servers wird also hierfür nicht benötigt.
Sie ist aber wunderbar einsetzbar für gleicheartige Anfragen des gleichen Clients an dasselbe Script (dieselbe Ressource). Die muss ja für jede Anfrage einen eigenen Variablenbereich in der Session eröffnen, wenn Mulit-Thread erlaubt sein soll.
Wozu eine Session? Wir reden von HTTP, da gibts erstmal keine Session. Und die Abschottung der einzelnen Webserver-Prozesse gegeneinander darf man als gegeben voraussetzen, die überschreiben sich ihre eigenen Variablen erst einmal nicht.
Wenn Du also einen (mehrstufigen) Datenbank-Suchvorgang vom selben Client mehrfach öffnest, also z.B. drei Suchfenster aufmachst für Kunden, um die Eintragungen vergleichen zu können, dann muss in der Session (es ist ja immer dieselbe) auch für alle drei Suichprozesse der aktuelle Zustand gespeichert werden.
Wenn man für so eine Aufgabe einen Sessionmechanismus bemühen möchte, könnte das sein. Ohne Sessions kommt man prima ohne sie aus.
Im Suchfomrular wird aleo eine eindeutige ID benötigt, um dem Fenstern auf dem Client (also den Formularen) immer den passenden Speicherblock zuordnen zu können.
Session-ID plus beliebiger Counter in der Session würden das perfekt erledigen.
Die Unique-Id wird in diesem Beispiel also dafür benutzt, um das "Speicherobjekt" in der Session eindeutig zuordnen zu können, da der Client gleichzeitig drei Threads derselben Klasse eröffnet hat.
Wenn ich in einer Session einen Speicherbereich für den ersten, zweiten, dritten etc... Suchvorgang anlegen müßte, würde ich numerisch aufwärts zählen und diesen Index als Parameter weiterreichen - nicht die doch eher obskure UniqueID des Apachen nutzen, deren Verfügbarkeit mir nicht auf jedem Server garantiert ist. Alternativ uniqid().
- Sven Rautenberg
"Love your nation - respect the others."