Domanda

Nella mia comprensione di Servlet, il Servlet verrà istanziato dal Container, il suo metodo init () verrà chiamato una volta e il servlet vivrà come un singleton fino allo spegnimento di JVM.

Non mi aspetto che il mio servlet sia serializzato, poiché verrà costruito nuovo quando il server delle app viene ripristinato o viene avviato normalmente. Il servlet non deve contenere membri specifici della sessione, quindi non ha senso che venga scritto e ri-istanziato sul disco. C'è un uso pratico per questo?

Le mie preoccupazioni sono che ho inserito alcuni campi non serializzabili all'interno e quindi la mia app fallirà misteriosamente in un ambiente di produzione in cui si verificherà un diverso tipo di replica della sessione.

È stato utile?

Soluzione

Tecnicamente, credo che il contenitore servlet sia autorizzato a "passivare" l'oggetto servlet su disco, in modo simile a quello dei bean di sessione EJB. Quindi hai ragione a porre la domanda se la tua app fallirà a causa di campi non serializzabili.

In pratica, non ho mai sentito parlare di un container che lo fa, quindi in realtà è solo un bagaglio ereditato dai brutti vecchi tempi dei primi J2EE. Non me ne preoccuperei.

Altri suggerimenti

HttpServlet dovrebbe essere serializzato su disco e sopravvivere al riavvio del contenitore servlet. Ad esempio Tomcat ti consente di impostare flag che consentono questo tipo di sopravvivenza. L'opzione successiva è il trasferimento tramite JNDI. Questa non è spazzatura, viene utilizzata solo in casi di utilizzo estremo.

Google sembra suggerire che ciò sia stato fatto in modo che gli autori di container possano avere l'opzione, se lo desiderano.

Hai ragione sul fatto che il servlet non dovrebbe contenere membri specifici della sessione, in effetti penso che vorresti il ??minimo stato possibile. Se memorizzi tutto in Session o ServletConfig, penso che sarai in grado di sopravvivere alla serializzazione.

Proprio come gli oggetti Session sono serializzati per sopravvivere nella cache per quei servletcontainer che danno l'opzione cluster, potrebbe esserci un'opzione per un container per trasferire un'istanza Servlet e un altro nodo cluster ?? Sto solo indovinando qui

Serializable viene utilizzato come interfaccia marker per gli attributi della sessione in ambiente distribuito.

  

Ambienti distribuiti SRV.7.7.2 (JSR-154)

     

All'interno di un'applicazione contrassegnata come distribuibile , tutte le richieste   fanno parte di una sessione devono essere gestiti da una Java Virtual Machine   (& # 8220; JVM & # 8221;) alla volta. Il contenitore deve essere in grado di gestire tutti gli oggetti   inserito in istanze della classe HttpSession utilizzando setAttribute   o metodi putValue in modo appropriato. Le seguenti restrizioni sono   imposto per soddisfare queste condizioni:

     
      
  • Il contenitore deve accettare oggetti che implementano l'interfaccia serializzabile .
  •   
  • La migrazione delle sessioni sarà gestita da strutture specifiche per container.
  •   
     

Il contenitore servlet distribuito deve generare un   IllegalArgumentException per oggetti in cui il contenitore non può   supportare il meccanismo necessario per la migrazione della memorizzazione della sessione   li .

     

Il contenitore servlet distribuito deve supportare il meccanismo necessario   per    migrazione di oggetti che implementano serializzabile .

     

(...)

     

Il provider di contenitori può garantire scalabilità e qualità del servizio   funzioni come il bilanciamento del carico e il failover di che hanno la possibilità di   sposta un oggetto sessione e il suo contenuto da qualsiasi nodo attivo di   sistema distribuito su un diverso nodo del sistema. Se distribuito   container persistono o migrano sessioni per fornire qualità di   funzionalità del servizio, non sono limitate all'uso della JVM nativa   Meccanismo di serializzazione per serializzare HttpSession e loro   attributi. Agli sviluppatori non è garantito che i container chiameranno   Metodi readObject e writeObject sugli attributi della sessione, se presenti   implementarli, ma è garantita la chiusura serializzabile di   i loro attributi saranno conservati .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top