Come posso ridimensionare il contesto di applicazione della molla?

5

Attualmente sto lavorando a un progetto che deve essere scalato dinamicamente su richiesta in base alle esigenze.

La mia domanda riguarda il ridimensionamento del contesto primaverile. La mia applicazione web ha un nucleo multi modulo classico (servizio, persistenza, dominio), che usa l'applicazione client (webapp, api).

L'applicazione per l'utente finale potrebbe essere raggruppata, anche il database, ma non so come procedere con il contesto di primavera.

Ho intenzione di usare gli attori di Scala Akka nel servizio di primavera, ma non posso essere persuaso dalla soluzione dell'uso di un contesto esposto dagli attori. Tutto il resto dell'applicazione è costruito con tecniche basate su eventi (gli eventi primaverili sono prodotti dal livello di servizio).

Ho già creato diverse webapp per profilo utente in scala in base al ruolo dell'utente (ad esempio admin, enduser), tuttavia l'unica cosa è Spring Context per le operazioni commerciali.

Domanda: Devo unirmi in un unico contesto condiviso da tutte le applicazioni client o dovrei inizializzare un contesto per applicazione?

http://i.stack.imgur.com/0ysv7.png

    
posta Zenithar 11.02.2013 - 14:41
fonte

1 risposta

1

È piuttosto difficile capire i tuoi diagrammi, come è la sezione front-end sulla parte sinistra è l'intera architettura dell'applicazione client ?? e la sezione giusta è il lato server? anche se, lo è, non riesco ancora a capire perché hai il database e il layer di prim'ordine nel front-end? È un database univoco locale per ogni applicazione client?

Ma per dare la mia idea, la tendenza comune nell'uso del contesto applicativo di Spring lo sta facendo come singleton che significa un contesto primaverile sul lato server, questo è l'essenza di esso, oppure hai già sfidato il suo scopo. I bean (ad es. I servizi) dovrebbero essere privi di stato, in modo da non produrre risultati indesiderati che i problemi di concorrenza potrebbero derivare da più di un client che richiede la stessa cosa e avrebbe bisogno di utilizzare gli stessi bean / servizi. rendendoli singleton, naturalmente, è il modo ideale per risparmiare memoria ed evitare la creazione di istanze su richiesta e dopo l'uso serve solo per essere raccolto. Non ci sarà collo di bottiglia, ma invece sarebbe più veloce perché l'oggetto è già caricato in memoria e ogni richiesta avrà il suo heap quando eseguirà quell'oggetto una volta chiamato. Quindi, in pratica, Singleton è più veloce e risparmia più memoria.

    
risposta data 20.02.2013 - 14:49
fonte

Leggi altre domande sui tag