Serializzazione delle sessioni in ambiente JavaEE

2

Considerare il seguente scenario:

Stiamo lavorando a un progetto JavaEE per il quale la scalabilità inizia a diventare un problema. Fino ad ora, siamo stati in grado di scalare ma questa non è più un'opzione. Pertanto, dobbiamo considerare la possibilità di ridimensionare e preparare l'app per un ambiente cluster.

La nostra principale preoccupazione in questo momento è la serializzazione delle sessioni utente. Purtroppo, non abbiamo considerato fin dall'inizio il problema e stiamo incontrando la seguente excetion:

java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.catalina.session.StandardSessionFacade

Ho fatto qualche ricerca e questa eccezione è generata perché ci sono oggetti memorizzati nella sessione che non implementano l'interfaccia Serializable . Considerando che in tutta l'app ci sono parecchi oggetti personalizzati che sono memorizzati nella sessione senza implementare questa interfaccia, richiederebbe molto lavoro e dedizione tediosi per correggere tutte queste dichiarazioni delle classi.

Fisseremo tutte queste dichiarazioni, ma la preoccupazione principale è che, in futuro, ci possa essere uno sviluppatore che aggiungerà un oggetto non Serializable nella sessione e interromperà la serializzazione e l'amp; replica su più nodi.

Come rapida panoramica del progetto, stiamo sviluppando utilizzando un framework nazionale basato su Struts 1 con l'API Servlet 3.0. Ciò significa che a questo punto, stiamo utilizzando lo standard session.getAttribute() e session.setAttribute() per lavorare con la sessione e la gestione della sessione è sparsa su tutto il codice base.

Oltre all'aggiornamento delle classi degli oggetti archiviati in sessione e assicurandoci di implementare l'interfaccia Serializable , quali altre misure di precauzione dovremmo adottare al fine di garantire un'affidabile capacità di replica di sessione sul livello applicazione? So che è un po 'tardi per considerarlo, ma quale sarebbe la migliore pratica in questo caso? Inoltre, ci sono altri problemi che dovremmo prendere in considerazione per questa transizione?

Grazie in anticipo!

    
posta Ionut 02.06.2014 - 22:28
fonte

1 risposta

3

Se si sta considerando solo un ambiente in scala ridotta, in cluster, con sessioni replicate, non si ha una soluzione alternativa. Tutti i tuoi oggetti devono essere serializzabili.

Ma se la tua applicazione e l'architettura Java EE ti consentono di eseguire un ambiente "clustered" scalato senza sessioni replicate , allora stai bene. L'unica cosa che perderai qui è la possibilità di mantenere un utente connesso e reindirizzato su un altro server quando quello che stava interagendo era spento per qualche motivo. Questo utente può essere reindirizzato su un altro server, ma dovrà riconnettersi e se la tua applicazione non è abbastanza intelligente, dovrà ricominciare da capo ciò che sta facendo, da capo.

Se davvero non puoi assicurarti che i tuoi oggetti siano serializzabili, considera un bilanciamento del carico per i contenitori web Java EE "non cluster" (gli EJB possono continuare a essere raggruppati e potrebbero darti una maggiore scalabilità) con HttpSession di sessione e non replicati.

    
risposta data 09.06.2014 - 09:52
fonte

Leggi altre domande sui tag