Comme vous le savez, les applications JSP ont le concept d'un objet Session afin de gérer plusieurs requêtes HTTP. En effet, le protocole HTTP est sans état et Session est utilisé pour maintenir l'état de l'utilisateur sur plusieurs requêtes HTTP.
Dans une configuration de serveur Web unique, il n'y a pas de problème, mais dès que vous disposez d'une batterie de serveurs Web à charge équilibrée multi-serveurs exécutant une application JSP, vous rencontrez immédiatement le problème de savoir où conserver la session. En effet, un équilibreur de charge aime idéalement acheminer chaque requête HTTP vers le serveur Web le plus approprié. Mais, si la session n'est conservée que sur un seul serveur Web, vous êtes obligé d'utiliser la fonction de session persistante de l'équilibreur de charge où il envoie les demandes liées à une session donnée uniquement au serveur Web sur lequel réside la session.
Cela signifie qu'un serveur Web peut être submergé même lorsque vous avez un autre serveur Web inactif, car la session de cet utilisateur réside sur ce serveur Web. Cela entrave bien sûr l'évolutivité. De plus, conserver l'objet Session uniquement sur un serveur Web signifie également la perte de données de session si ce serveur Web tombe en panne pour une raison quelconque.
Pour éviter ce problème de perte de données, vous devez disposer d'un mécanisme dans lequel la session est répliquée sur plusieurs serveurs Web. Ici, les principaux moteurs de servlet (Tomcat, WebLogic, WebSphere et JBoss) fournissent tous une certaine forme de persistance de session. Ils incluent même une certaine forme de réplication de session, mais tous ont des problèmes. Par exemple, la persistance basée sur les fichiers et JDBC est lente et entraîne des problèmes de performances et d'évolutivité. La réplication de session est également très faible car elle réplique toutes les sessions sur tous les serveurs Web, créant ainsi des copies inutiles de la session lorsque vous avez plus de deux serveurs Web, même si la tolérance aux pannes peut être obtenue avec seulement deux copies.
Dans de telles situations, un cache distribué Java comme NCache est votre meilleur pari pour garantir que la persistance de la session sur plusieurs serveurs dans le cluster Web se fait de manière très intelligente et sans entraver votre évolutivité. NCache dispose d'une topologie de mise en cache appelée "Partition-Replica" qui vous offre non seulement une haute disponibilité et un basculement via la réplication, mais également un stockage de session en mémoire important via le partitionnement des données. Le partitionnement des données vous permet de mettre en cache de grandes quantités de données en divisant le cache en partitions et en stockant chaque partition sur différents serveurs de cache dans le cluster de cache.
NCache La topologie de partition-réplication réplique les données de session de chaque nœud sur un seul autre nœud du cluster. Cette approche élimine les implications de performances de la réplication des données de session sur tous les nœuds de serveur sans compromettre la fiabilité.
De plus, la persistance de session fournie par les serveurs Web (Apache, Tomcat, Weblogic et WebSphere) utilise les ressources et la mémoire du cluster Web. Cette approche entrave les performances de votre application, car les nœuds de cluster Web chargés de traiter la demande du client gèrent également le travail supplémentaire de réplication de session et son stockage en mémoire. Alors que vous pouvez courir NCache sur des boîtes distinctes autres que la partie de votre cluster Web. De cette façon, vous pouvez libérer les ressources du cluster Web et le cluster Web peut utiliser ces ressources pour gérer de plus en plus de demandes de clients.
Pour la persistance de session JSP, NCache a mis en place un module de session NCacheSessionProvider en tant que filtre Java. NCache Le filtre de servlet JSP intercepte dynamiquement les requêtes et les réponses et gère la persistance des sessions en arrière-plan. De plus, vous n'avez pas à modifier le code de votre application JSP.
Voici un exemple NCache Configuration du filtre de servlet JSP que vous devez définir dans votre descripteur de déploiement d'application à utiliser NCache pour la persistance de la session JSP :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<filter> <filter-name>NCacheSessionProvider</filter-name> <filter-class> com.alachisoft.ncache.web.sessionstate.NSessionStoreProvider </filter-class> </filter> <filter-mapping> <filter-name>NCacheSessionProvider</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <init-param> <param-name>cacheName</param-name> <param-value>PORCache</param-value> </init-param> <init-param> <param-name>configPath</param-name> <param-value>/usr/local/ncache/config/</param-value> </init-param> |
Par conséquent, NCache vous fournir un mécanisme bien meilleur pour atteindre la persistance de session dans le cluster Web ainsi que l'amélioration des performances et l'évolutivité.
Alors, téléchargez une version d'essai complète de 60 jours de NCache Enterprise et essayez-le par vous-même.