Quels sont les inconvénients de la réplication de session sur Tomcat?

je peux souligner les considérations suivantes si vous optez pour la réplication de session.

Performances

le principal inconvénient sera sur la performance. Les sessions répliquées impliquent la copie de données de session sur tous les serveurs du cluster. Plus vous avez de serveurs dans le cluster, plus de frais généraux sont impliqués.

Tomcat aide avec cette fonction en définissant deux modes de réplication de session.

DeltaManager (par défaut) et BackupManager

à Partir de cette URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

L'utilisation de la configuration ci-dessus va permet la réplication de la session all-to-all utiliser le DeltaManager pour répliquer session deltas. Par tout-à-tout nous dire que la session répliqué à tous les autres nœuds du cluster. Cela fonctionne très bien pour les plus petits clusters mais nous ne le recommandons pas pour les grands clusters (beaucoup de tomcat nœud.) Également lors de l'utilisation du delta de gestionnaire de répliquer à tous les noeuds, même les noeuds que n'avez pas l'application déployer.

Pour contourner ce problème, vous devriez utiliser le Gestionnaire de sauvegarde. Ce gestionnaire ne fait que reproduire les données de session à un noeud de sauvegarde, et seulement aux noeuds qui ont le application déployée. La baisse de la BackupManager: pas tout à fait comme la bataille testé comme le gestionnaire delta

Lire this URL pour bons conseils de conception pour le cluster si vous activez la réplication de session.

Mémoire

combien d'utilisateurs concurrents vont frapper l'application? plus il y a d'utilisateurs, plus les données sont stockées dans les sessions, et donc une surcharge pour la réplication des sessions.

Considérations relatives au Code

de plus, vous devez vous assurer que les données mises dans la session par l'application sont sérialisables. Les données des sessions de sérialisation ont un certain les frais généraux pour la réplication de l'état de la session. C'est une bonne idée de garder la taille de la session assez petite, de sorte que les développeurs doivent vérifier la quantité de données mises dans la session.

Collant Sessions

compte tenu de ces considérations, cela dépend en fait de la criticité des cas d'utilisation. Si vous allez pour les sessions collantes seul, alors il y a une chance de perte de données d'utilisateur pendant un voyage critique.

avez-vous les moyens de vous en remettre? - par exemple: en persisitant des données critiques dans la base de données à chaque étape d'une commande ou d'un voyage de paiement? Si l'utilisateur doit se connecter et commencer à nouveau. C'est très bien pour les sites Web qui ne sont pas transactionnels, mais parcourir brochureware type de données ou remplir des formulaires pour saisir des données qui ne sont pas de paiement, etc.