Devo usare i bean Session Spring Session o una cache come ehcache?

Question

Abbiamo un'app che deve mantenere lo stato in modo che alcuni oggetti contenenti dati (potenzialmente molti) possano essere interrogati da un client (browser) in un'interazione "conversazionale". Non sarebbe efficiente ricaricare i dati con ogni richiesta.

Utilizziamo i bean con ambito Spring e di sessione per mantenere alcuni dati controllati dalla sessione. Tuttavia questi nuovi fagioli sarebbero più grandi.

Questo sarebbe un uso appropriato dei bean con scope di sessione o una cache (ehcache) dovrebbe essere più adatta?

Siamo riluttanti a introdurre una tecnologia di caching a meno che non sia necessario.

L'altro fattore è che l'applicazione dovrà essere distribuita in un cluster. In tal caso i bean con scope di sessione dovrebbero essere replicati dalla replica della sessione del server delle applicazioni o sarebbe più efficiente utilizzare ehcache (che credo possa essere distribuito in un cluster)?

Qualsiasi consiglio apprezzato.

Answer 1

Coppia di pensieri su questo (disclaimer: io lavoro per il cotto/EHCache ... in modo da tenere a mente ... ma ancora cercando di essere imparziale qui):

1 - C'è qualche dati ridondanti a ciascuna delle sessioni? Qualcosa che potrebbe essere condiviso attraverso le sessioni? Se sì, +1 per ehcache per archiviare le cose condivise (perché ehcache è ottimizzato per una concorrenza pesante)

2 - Quanto saranno grandi gli oggetti della sessione? E quanti utenti concorrenti ti aspetti su base stabile? (in altre parole, quanta memoria hai intenzione di dedicare allo storage di sessione sul tuo server delle app?)

Se l'ingombro della sessione non è così grande e può adattarsi bene all'heap senza problemi di GC, quindi utilizzare la sessione dovrebbe essere una soluzione eccellente.

Ma più grande diventa, più grande sarà il tuo heap java ... e più dovrai usare i trucchi voodoo per tenere sotto controllo i garbage collection e i tempi di pausa gc. Utilizzando ehcache, è possibile archiviare centralmente alcuni oggetti a cui possono accedere più sessioni ... consolidando quindi il footprint di memoria (stesso punto 1) Inoltre, utilizzando l'estensione aziendale per ehcache (BigMemory = http://terracotta.org/products/bigmemory), è possibile ignorare l'heap limitazioni e archiviare i dati off-heap (quanto necessario: 10, 100 o più GB). Con ciò, la dimensione degli oggetti che devono essere in memoria diventa irrilevante (purché sia ​​possibile aggiungere RAM al server ovviamente)

3 - Per la replica di sessione, server di app come JBOSS, Weblogic, supporto Websphere esso. Di nuovo, si tratta ancora di dimensioni della sessione (quanti dati dovranno essere replicati attraverso il filo). Se gli oggetti di sessione sono grandi e ne hai molti, ci sarà molto traffico di rete nel tuo cluster ... potrebbe o non potrebbe funzionare bene. Avere gli oggetti di base in un layer EhCache distribuito ottimizzato per l'archiviazione dei dati, mantenendo al minimo la sessione (ovvero le informazioni di accesso/autenticazione) migliorerebbe sicuramente il meccanismo di replica della sessione secondo me.

Spero che questo aiuti.