Nous utilisons Spring Session (sauvegardé avec Gemfire pivotant) pour nos applications Spring Boot fonctionnant dans un environnement distribué.Unicité de l'ID de session dans un environnement distribué?
Dans un tel environnement distribué,
session de printemps ne s'assurer qu'un identifiant de session unique est utilisé pour de nouvelles sessions en cours de création dans différents JVMs?
En passant, vieux SO messages pour soutien Session de printempsPivotal GemFire , donc mes excuses à votre question ne se sont répondu en temps opportun.
En résumé, Spring Session utilise la classe UUID pour générer des ID de session "uniques". Par exemple, voir here, ou plus généralement, here.
NOTE: Session de printemps de données Redis soutien uses/wraps la classe MapSession pour stocker l'état de session dans Redis, par défaut.
Il semble y avoir beaucoup de discussion sur l'efficacité, ou plutôt l'unicité, de UUID sur les JVM d'un cluster. Ce one in particular, bien que daté, a attiré mon attention car il provient des forums de la communauté Oracle Java. Cependant, gardez à l'esprit que c'est l'utilisation de votre application Spring Session qui détermine finalement si les ID de session sont uniques; c'est-à-dire qu'il ne dépend pas du nombre de nœuds dans un cluster GemFire puisque des nœuds GemFire individuels ne génèrent pas l'ID de session (les applications utilisant Spring Session sont). Par conséquent, si une seule application (probablement peu probable dans l'état Microservices du monde) est présente avec Spring Session en cours d'utilisation, les UUID sont garantis probabilistes comme étant uniques. Même alors, sur la base de references disponible, il semble hautement improbable que 2 nœuds "application" ou plus utilisant Spring Session génèrent des identifiants qui se rencontrent (bien que (presque?) Tout soit possible ;-).
Bien, je suppose que si elle est une préoccupation/une importance capitale, à la suite de la belle tradition de printemps, ce serait une simple question à étendre la GemFireOperationsSessionRepository et passer outre la méthode createSession(), appelant le GemFireSession approprié constructor Cependant, dans tous les cas (GemFire, Redis, etc.), le problème d'unicité de l'ID de session est indépendant du stockage de données de sauvegarde sous-jacent.
Espérons que cela aide ...
Cheers!