nikosch

Ich will mal wieder eine Allgemeinfrage aufwerfen.

Das Sessionarray ist ja ein begrenzter Namensraum mit konkurrierenden Schlüsseln. Wie organisiert Ihr eigentlich Eure Sessions? Habt Ihr Euch mal die Mühe gemacht, hier Konzepte zu erstellen, vielleicht sogar allgemeingültige Richtlinien? Oder wächst sowas bei Euch immer organisch.

(Fast) spontan fallen mir z.B. folgende Bereich ein, die eine Session abdecken kann:

- persistent: serialisierte Domainobjekte, (Authobjekt)
- dynamic application: Authsettings, Formdaten aus Eingaben über mehrere Seiten
- cached: sonstige serialisierte Daten (e.g. Konfiguration der Applikation)
- global: globale Settings (e.g. aktuelle Page/History, Sprachsetting, Initial-Referrer ...)
- global view: Browserbestimmung, Userstylesheets ...
- dynamic view: Redo für Ajax-Zustände nach Request


Klingt jetzt vielleicht speziell, aber Ihr wisst sicher, worauf ich hinaus will? Hat irgendwer Erfahrungswerte?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

boolean

Sessions sind ein heikles Thema wenn man beachtet, dass es wirklich nicht einfach ist eine Webseite mit einem Bereich, in dem man sich authentifizieren muss sicher zu halten. Ich stande auch erst vor kurzen vor einem Problem, dass etwas schwer zu lösen war, da es mehrere Fehler serverseitig gegeben hat und diese Fehler nicht ohne weiteres von heute auf morgen behoben worden konnten.

Zu deiner eigentlichen Frage: Ein direktes Konzept habe ich nicht. Ich habe Namensräume noch einmal verschachtelt hierfür nutze ich (meistens) Zend_Session - allerdings gibt es auch hier nachteile.

Ein wesentlicher ist es (so finde ich), dass egal bei welcher Session-Lösung das Problem auftritt: Wenn man beispielsweise einen Loadbalancer mit mehreren Webservern dahinter hat und während eines Laufs wird der Benutzer (entweder versehentlich oder beabsichtigt) auf einen anderen Webserver übertragen so verschwindet die Session was dann wiederrum zur folge hat, dass der Benutzer bspw. seinen Warenkorb oder ähnliches verlieren würde.

Die von dir o.g. Namespaces erscheinen mir für etwas "zu weit ausgedehnt", da es doch so ist, dass diverse Konfigurationen (Userstylesheets oder auch Konfigurationen oder einen teil einer Applikation) nichts in der Session verloren habe. Natürlich - ich geb dir Recht - es ist Ansichtssache und jeder hält andere Sachen für "unschön", was ggf. ein anderer wiederum für gut heißt.

Ich würde jedoch sagen, dass für eine Sessionverwaltung folgende Lösung am besten ist:
Zusätzlich zur eigentlichen Session wird bei aktionen die Session im Cache (Apc, Memcached, File oder Ähnliches gehalten), sofern dieser global aufrufbar ist, was bspw. bei File nicht der Fall sein dürfte.

Weiterhin: Um eine genau Antwort geben zu können auf deine Frage müsstest du schon ein wenig konkreter werden. Modelle gibt es viele - aber die meisten davon bringen nichts, für das eigene Projekt - wie man weis ist jeder anders!

Gruß,

boolean

robo47

Das lässt sich über ein eigenes Backend für die Session machen.
Man braucht nur einen zentralen Speicherort (zentraler Server, Memcache, DB (memory-table)) auf den alle Webserver Zugriff haben.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

boolean

Genauso habe ich es gelöst (Cache).

nikosch

Naja, ich sag mal so: bei datenbankbasierten Sessions erübrigt es sich natürlich, das eine oder andere Datum nochmal in die Session zu schreiben. Ich will jetzt eigentlich auch keine Diskussion über die Sinnhaltigkeit jedes der genannten Punkte führen. Mir geht es um die eigentliche Frage. Die o.g. Labels sind auch keine Namespaces, ich habe bloss versucht, mögliche Inhalte mal nach Funktion zu klassifizieren.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

boolean

Also ich habe mich gerade eben für Datenbank-Sessions im aktuellen Projekt entschieden. Auf was möchtest du dann raus?

nikosch

Auf nichts konkretes, schon gar nicht auf Implementierungsdetails.
Wenn Du dabei session_set_save_handler benutzt, hast Du ja trotzdem das Problem, dass Daten im $_SESSION Array um die Schlüssel konkurrieren. Hast Du so wenige Daten in der Session, dass das irrelevant ist?

Ich suche Überlegungen zu sinnvollen Sessionstrukturen oder eine Art "Session Design Patterns".

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

yab

Das ist doch im Prinzip der Aufbau eines INI-Files. Dort hast du Schlüssel-/Werte-Paare die in Sektionen unterteilt sind. Die Sektionen wären dann deine obige Klassifikation.
Die Konfigurationsklassen mit den Methoden get($Section, $Key) und set($Section, $Key, $Value) kann man doch 1 zu 1 auch für Sessions übernehmen. Ich verstehe jetzt nicht so genau, worauf du hinaus möchtest.

nikosch

Nochmal: Nicht auf die Implementierung, sondern auch die Struktur.

Infiles sind auch nicht vergleichbar, schon weil sie nur max. 2-dimensional verwalten können.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Celli

Ich habe zwar nie Session-Gruppen für unterschiedliche Anwendungsziele erstellt, aber ich denke, dass wenn man es bräuchte, es sich mit Prefixes in den Session-Keys gut organisieren lassen könnte, besonders wenn es Objekt relevante Inhalte sind. Die Lebenszeit der einzelnen Werte oder (virtuelle) Gruppen wäre über eine LifetimeTable in einer der Session Variablen leicht zu verwalten.

__________________
Eine Antwort oder Lösung habe ich nicht immer, aber zu 99,9% eine Idee. (200 Posts Limit)