Normal
Ja, so könnte ich mir das vorstellen.Der Client erstellt eine Session (SFSB), authentifiziert sich gegenüber dem Server. Das SFSB kann das Singleton Bean injiziert bekommen. Dieses Bean hält die kontextabhängigen Daten, Schlüssel sind die Prinzipalinformationen (also der User). Das SFSB sollte über create und destroy die Lebensdauer des Kontextes steuern.Wenn jetzt ein User mehrere Sessions gleichzeitig haben soll (mit unterschiedlichen Kontexten), könnte man die Prinzipalinformationen um eine auf Clientseite generierte ID erweitern, die dazu dient die Session zu identifizieren. Diese ID kann dann als Schlüssel verwendet werden.
Ja, so könnte ich mir das vorstellen.
Der Client erstellt eine Session (SFSB), authentifiziert sich gegenüber dem Server. Das SFSB kann das Singleton Bean injiziert bekommen. Dieses Bean hält die kontextabhängigen Daten, Schlüssel sind die Prinzipalinformationen (also der User). Das SFSB sollte über create und destroy die Lebensdauer des Kontextes steuern.
Wenn jetzt ein User mehrere Sessions gleichzeitig haben soll (mit unterschiedlichen Kontexten), könnte man die Prinzipalinformationen um eine auf Clientseite generierte ID erweitern, die dazu dient die Session zu identifizieren. Diese ID kann dann als Schlüssel verwendet werden.
