2010-07-09 6 views
5

La domanda è un po 'lunga dal momento che è concettuale. Spero non sia una cattiva lettura :)Controller (Spring Managed Bean) Scopo Domanda: Singleton, Request or Session?

Sto lavorando a un'applicazione web MVC/Tiles di Spring Performance (carico tipico di 10.000 utenti). Carichiamo una schermata di aggiornamento dei dipendenti, in cui viene caricata una schermata dei dettagli dei dipendenti (associata a un oggetto aziendale dipendente) per gli aggiornamenti tramite un MultiActionController. Ci sono più schede su questa schermata, ma solo la tab1 ha i dati aggiornabili. Resto delle schede sono roba di sola lettura, per riferimento sostanzialmente.

Inutile dire che abbiamo deciso di caricare queste schede di sola lettura in modo lazy, vale a dire, quando ciascuna scheda è attivata, generiamo una chiamata ajax (una tantum) per recuperare i dati dal server. Non cariciamo tutto tramite il metodo di caricamento della vista di aggiornamento. Ricorda: questa è una volta, dati di sola lettura.

Ora, sono in un dilemma. Ho creato un altro controller multiaction, denominato "AjaxController" per la gestione di queste chiamate Ajax. Ora, le mie domande:

  1. Quale dovrebbe essere lo scopo migliore per questo controller?

Pensieri: se si effettua la richiesta con scope, quindi 10.000 utenti possono creare insieme 10.000 istanze di questo bean: problema di memoria lì. Se lo faccio scopare in sessione, ne verrà creato uno per sessione utente. Ciò significa che quando 10.000 utenti accedono all'app, indipendentemente dal fatto che abbiano eseguito il metodo AjaxController, avranno entrambi un bean in possesso.

  1. Quindi, Singleton è lo scopo migliore per questo controller?

Riflessioni: Un bean singleton verrà creato durante gli stivali primaverili, e questa stessa istanza verrà fornita dappertutto. Suona bene.

  1. I metodi del gestore (come fetchTab7DataInJsonFormat) devono essere statici e collegati alla classe?

Pensieri: In questo caso, è possibile che i metodi statici siano in conflitto semanticamente con l'ambito? Ad esempio: scope = "session"/"request" + metodi statici hanno senso? Chiedo perché anche se ogni sessione utente ha il proprio bean AjaxController, i metodi del gestore sono effettivamente associati alla classe e non alle istanze. Inoltre, scope = "singleton" + metodi di gestione statica ha senso?

  1. Posso implementare manualmente il modello di progettazione singleton in AjaxController?

Pensieri: Cosa succede se controllo la creazione: esegui il singleton GoF in pratica. Quindi cosa può fare la specifica dell'ambito? La sessione/richiesta dell'ambito sicuramente non può creare più istanze, vero?

  1. Se, con qualsiasi meccanismo (specifica bean/modello di progettazione/metodi statici), riesco ad avere un'unica istanza di AjaxController: Questi metodi STATIC devono essere sincronizzati? Penso di no, perché anche se i metodi di gestione STATIC possono comunicare con i servizi (che parlano con DB/WS/MQ ecc.), Ci vuole tempo, penso che ogni thread di richiesta che immette i metodi statici verrà restituito dal proprio ID del thread giusto? Non è come se l'utente1 inserisse il metodo statico, quindi user2 immette il metodo statico prima che sia restituito all'utente1 e quindi entrambi ottengono dei dati confusi? Probabilmente è sciocco, ma voglio essere sicuro.

Sono confuso. Fondamentalmente voglio esattamente una singola istanza del bean controller che gestisca tutte le richieste per tutti i client.

Nota importante: il bean AjaxController non è INIETTATO da nessun'altra parte, esiste isolato. I suoi metodi vengono colpiti tramite chiamate Ajax.

risposta

3

Se lo facessi, farei sicuramente il singleton LazyLoadController senza avere metodi statici e senza alcun stato in esso.

Inoltre, non è assolutamente necessario istanziare manualmente i singleton, è meglio usare il meccanismo comune di Spring e lasciare che il framework controlli tutto.

L'idea generale è di evitare l'uso di metodi statici e/o dati persistenti nei controller. Il meccanismo giusto sarebbe utilizzare alcuni bean di servizio per generare dati per la richiesta, quindi il controllore agisce come dispatcher dei parametri di richiesta per recuperare i dati nella vista. Nel controller non è consentito lo stato mutabile o roba concorrente non sicura. Se alcuni componenti sono specifici dell'utente, il sistema AOP di Spring fornisce l'iniezione dei componenti in base alla sessione/richiesta.

Si tratta di buone pratiche nel fare cose del genere. C'è qualcosa da chiarire per dare una risposta più specifica per il tuo caso. Ho capito bene che il tipico caso d'uso sarà che AjaxController trasmetterà alcune richieste a LazyLoadController per ottenere i dati delle schede? Si prega di fornire dettagli a riguardo nel commento o nella domanda, in modo che possa aggiornare la mia risposta.

La cosa che non va con i metodi statici nel controller è che devi gestire la sicurezza simultanea da solo, che non è solo soggetta a errori ma ridurrà anche le prestazioni generali. Spring esegue ogni richiesta nel proprio thread, quindi se due chiamate simultanee devono utilizzare un metodo statico e ci sono risorse condivise (quindi è necessario utilizzare l'istruzione di sincronizzazione oi blocchi), uno dei thread dovrà attendere il completamento di un altro nel blocco protetto. D'altra parte, se si utilizzano i servizi stateless e si evitano di avere dati che possono essere condivisi per più chiamate, si ottiene un aumento delle prestazioni e non è necessario occuparsi dell'accesso simultaneo ai dati.

+0

Un enorme errore da parte mia. LazyLoadController IS AjaxController. Ho pensato ad un nome mentre iniziavo a scrivere domande, e poi tornavo a un altro nome durante le domande. Le mie scuse, ho modificato il post. Sì, hai il diritto di utilizzare. In effetti, ho un livello di servizio che fa esattamente questo, e questo AjaxController agisce semplicemente come un dispatcher di richieste e un gestore di risposta. Alcuni dei miei dubbi rimangono riguardo agli scenari di conflitto. Attualmente il mio AjaxController è single, e ha metodi statici per elaborare le richieste e interagire con il livello di servizio. Qualcosa non va in questa configurazione? – SpringConfused

+0

Vedo. Aggiornato la mia risposta con la spiegazione del perché i metodi statici sono sbagliati. –