2008-09-17 3 views
4

Tomcat (version 5 ici) stocke les informations de session en mémoire. Lors de la mise en cluster, ces informations sont régulièrement diffusées sur d'autres serveurs du cluster pour que les données restent synchronisées. Vous pouvez utiliser un magasin de base de données pour rendre les sessions permanentes, mais ces informations sont uniquement écrites périodiquement et ne sont réellement utilisées que pour la reprise après incident plutôt que pour le remplacement réel des sessions en mémoire.Existe-t-il un moyen de spécifier un magasin de sessions différent avec Tomcat?

Si vous ne souhaitez pas utiliser de sessions persistantes (notre configuration ne le permet malheureusement pas), cela pose un problème de désynchronisation des sessions. Dans d'autres langues, les frameworks Web ont tendance à vous permettre d'utiliser une base de données en tant que magasin de session principal. Alors que cela introduit un problème de mise à l'échelle potentielle, cela rend la gestion de session très simple. Je me demande s'il existe un moyen de faire en sorte que tomcat utilise une base de données pour les sessions de cette manière (techniquement, cela supprimerait également le besoin d'une configuration de clustering dans le serveur tomcat.xml).

+1

Si vous n'utilisez pas de sessions persistantes, vous enfreignez l'une des exigences de la spécification de servlet: les requêtes pour la même session sont traitées à partir de la même JVM. Tomcat rend cela très dur. Vous allez probablement vous perdre - mettre à jour des problèmes avec la conservation des sessions dans une base de données. – davidsheldon

Répondre

3

Il y a certainement un moyen. Bien que je vote fortement pour des sessions collantes - économise tellement de charge pour vos serveurs/base de données (à moins que quelque chose échoue) ...

http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html a des informations sur la configuration de SessionManager et l'installation pour Tomcat. En fonction de vos besoins exacts, vous devrez peut-être implémenter votre propre gestionnaire de session, mais ce point de départ devrait vous aider.

2

Jetez un oeil à Terracotta, je pense qu'il peut répondre à vos problèmes de mise à l'échelle sans une refonte majeure de l'application.

2

J'ai toujours été fan de la technique des sessions Rails: stocker les sessions (compressées + chiffrées + signées) dans le cookie de l'utilisateur. De cette façon, vous pouvez équilibrer la charge avec le contenu de votre cœur et ne pas avoir à vous soucier des sessions persistantes ou de la base de données pour vos données de session, etc. Je ne suis pas sûr que vous puissiez facilement l'implémenter dans une application java. de réécriture de votre code d'accès à la session. De toute façon juste une pensée.

+1

Un cookie est très limité dans l'espace et le montant que vous êtes autorisé à allouer. Max ~ 20 cookies par domaine et max ~ 4KB par cookie. – BalusC

+0

Comment Rails fait-il face à la taille limitée des cookies? – cherit

2

Une autre alternative serait la memcached-session-manager, une solution de basculement de session et de réplication de session basée sur memcached pour tomcat 6.x/7.x. Il prend en charge les sessions collantes et les sessions non collantes.

J'ai créé ce projet pour obtenir le meilleur de la performance et de la fiabilité et pour pouvoir évoluer en ajoutant simplement plus de nœuds tomcat et memcached.

Questions connexes