Come sapete, le applicazioni JSP hanno il concetto di un oggetto Session per gestire più richieste HTTP. Questo perché il protocollo HTTP è senza stato e la sessione viene utilizzata per mantenere lo stato dell'utente su più richieste HTTP.
In una configurazione di un singolo server Web, non ci sono problemi, ma non appena si dispone di una Web farm con bilanciamento del carico multi-server che esegue un'applicazione JSP, si incontra immediatamente il problema di dove mantenere la Session. Questo perché un sistema di bilanciamento del carico preferisce instradare ogni richiesta HTTP al server Web più appropriato. Tuttavia, se la sessione viene conservata su un solo server Web, sei costretto a utilizzare la funzione di sessione permanente del servizio di bilanciamento del carico in cui invia le richieste relative a una determinata sessione solo al server Web in cui risiede la sessione.
Ciò significa che un server Web potrebbe essere sopraffatto anche quando l'altro server Web è inattivo perché la Session per quell'utente risiede su quel server Web. Questo ovviamente ostacola la scalabilità. Inoltre, mantenere l'oggetto Session solo su un server Web significa anche perdere i dati della sessione se quel server Web si interrompe per qualsiasi motivo.
Per evitare questo problema di perdita di dati, è necessario disporre di un meccanismo in cui Session viene replicata su più di un server Web. Qui, i principali motori servlet (Tomcat, WebLogic, WebSphere e JBoss) forniscono tutti una qualche forma di persistenza della sessione. Includono anche una qualche forma di replica della sessione, ma tutti hanno problemi. Ad esempio, la persistenza basata su file e JDBC è lenta e causa problemi di prestazioni e scalabilità. La replica della sessione è anche molto debole perché replica tutte le sessioni su tutti i server Web creando così copie non necessarie della sessione quando si hanno più di due server Web anche se la tolleranza agli errori può essere raggiunta con solo due copie.
In tali situazioni, una cache distribuita Java come NCache è la soluzione migliore per garantire che la persistenza della sessione su più server nel cluster Web avvenga in modo molto intelligente e senza ostacolare la scalabilità. NCache dispone di una topologia di memorizzazione nella cache denominata "Partition-Replica" che non solo fornisce alta disponibilità e failover tramite la replica, ma fornisce anche un'ampia sessione di archiviazione in memoria tramite il partizionamento dei dati. Il partizionamento dei dati consente di memorizzare nella cache grandi quantità di dati suddividendo la cache in partizioni e archiviando ciascuna partizione su server di cache diversi nel cluster di cache.
NCache La topologia Partition-Replica replica i dati della sessione di ciascun nodo su un solo altro nodo nel cluster, questo approccio elimina le implicazioni sulle prestazioni della replica dei dati della sessione su tutti i nodi del server senza compromettere l'affidabilità.
Inoltre, la persistenza della sessione fornita dai server Web (Apache, Tomcat, Weblogic e WebSphere) utilizza la risorsa e la memoria del cluster Web. Questo approccio ostacola le prestazioni dell'applicazione perché i nodi del cluster Web responsabili dell'elaborazione della richiesta del client gestiscono anche il lavoro aggiuntivo della replica della sessione e del relativo storage in memoria. Mentre, puoi correre NCache su caselle separate dall'altra parte del tuo cluster web. In questo modo puoi liberare le risorse del cluster Web e il cluster Web può utilizzare tali risorse per gestire un numero sempre maggiore di richieste dei client.
Per la persistenza della sessione JSP, NCache ha implementato un modulo di sessione NCacheSessionProvider come filtro Java. NCache JSP Servlet Filter intercetta dinamicamente richieste e risposte e gestisce la persistenza della sessione dietro le quinte. E non è necessario modificare il codice dell'applicazione JSP.
Ecco un esempio NCache Configurazione del filtro servlet JSP da definire nel descrittore di distribuzione dell'applicazione da utilizzare NCache per la persistenza della sessione 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> |
Quindi, NCache fornisce un meccanismo molto migliore per ottenere la persistenza della sessione nel cluster Web insieme a un aumento delle prestazioni e alla scalabilità.
Quindi, scarica una versione di prova di 60 giorni completamente funzionante di NCache Enterprise e provalo tu stesso.