MVC 3 svantaggi del contenitore tempdata

Question

Sebbene il titolo della domanda appaia un po 'soggettivo, sono sicuro che non c'è molto da discutere. Attualmente sto lavorando a un progetto MVC in cui sto utilizzando il contenitore TemData in alcune aree. Quando leggo la documentazione in MSDN, sembra che l'uso di TempData crei una sessione e che una volta letti i dati che memorizziamo in tempdata siano spariti. Sono d'accordo con questo concetto, tuttavia la cosa che mi ha infastidito questa mattina è come si comporta quando si ospita la propria applicazione in un ambiente Web Farm.

Che cosa succede se una richiesta GET viene passata al SERVER 1, che crea un TempData e la successiva richiesta GET/POST viene inviato al server 2.

potrei essere completamente sbagliato in questa ipotesi, ma ho solo bisogno di un chiarimento su questo coso.

Ogni ingresso sarà molto apprezzato ...

Cheers!

Answer 1

Dopo aver effettuato alcune ricerche, lo scenario che ho inserito nella mia domanda è inevitabile se si utilizzano le variabili di sessione nelle applicazioni. La cosa migliore che potremmo fare è ridurre la quantità di dati che potremmo archiviare in una sessione, oltre a questo se abbiamo ancora bisogno di usare le sessioni in un ambiente webfarm/multi server, ci sono alcune modifiche alla configurazione che è possibile apportare. Ecco un articolo molto utile su come è possibile gestire lo storage di sessione.

ASP.NET Session how to FAQs

Answer 2

Sì, per impostazione predefinita ASP.NET MVC memorizza TempData in sessione. Se la sessione è inproc (impostazione predefinita) e si è in una Web farm, è possibile che non si ottengano i dati di sessione corretti per la richiesta successiva. Se si è in un modulo Web, utilizzare un altro metodo di archiviazione di sessione come server di stato o server SQL.