Cosa mettere in una variabile di sessione

Question

Recentemente mi sono imbattuto in un ASP 1.1 applicazione web che ha messo un mucchio di roba nella variabile di sessione - compresi tutti i DB di dati oggetti e anche la connessione al DB oggetto.Si finisce per essere enorme.Quando il web timeout sessione (quattro ore dopo che l'utente ha terminato di utilizzare l'applicazione) a volte le loro transazioni di database ottenere il rollback.Sto assumendo questo è perché la connessione al DB non viene chiuso correttamente quando IIS uccide la sessione.

Comunque, la mia domanda è che cosa dovrebbe contenere una variabile di sessione?Chiaramente alcune cose hanno bisogno di essere lì.L'utente seleziona un piano che si desidera modificare nella schermata principale, in modo che il piano identificativo va in una variabile di sessione.È meglio per provare a ridurre il carico sul DB archiviando tutti i dettagli sull'utente (e il loro manager, etc.) e il piano che stanno modificando la variabile di sessione o devo cercare di ridurre al minimo la roba nella variabile di sessione e di eseguire query sul DB per tutto ciò che mi serve nell'evento Page_Load?

Answer 1

Questo è abbastanza difficile rispondere perché è così specifiche dell'applicazione, ma qui ci sono alcune linee guida che uso:

1. Mettere il meno possibile, in sessione.
2. Specifiche dell'utente selezioni che dovrebbe durare solo durante una visita sono una buona scelta
3. spesso, le variabili che devono essere accessibili a più pagine in tutto, l'utente visita il tuo sito (per evitare di passarli da una pagina all'altra) sono anche buoni da mettere nella sessione.

Da quel poco che hai detto circa la vostra applicazione, probabilmente sarei selezionare i dati dal db e cercare di trovare modi per ridurre al minimo l'impatto di tali query invece di caricare giù per la sessione.

Answer 2

Fare non mettere informazioni di connessione al database nella sessione.

Quanto riguarda la cache, vorrei evitare l'uso della sessione per la memorizzazione nella cache, se possibile, si incorrerà in problemi in cui qualcuno modifica i dati di un utente utilizza, più si può non condividere la cache di dati tra gli utenti.Utilizzare il ASP.NET Cache, o altre utilità di cache (come Memcached o la Velocità).

Per quanto riguarda quello che dovrebbe vai nella sessione, tutto ciò che si applica a tutti le finestre del browser, un utente ha aperto per il vostro sito (login, impostazioni di sicurezza, etc.) dovrebbe essere nella sessione.Cose come quello che l'oggetto è visto/a cura dovrebbe essere realmente GET/POST variabili passati in giro tra le schermate in modo che un utente può utilizzare più finestre del browser per lavorare con l'applicazione (a meno che non si desideri evitare che).

Answer 3

NON mettere gli oggetti dell'interfaccia utente in sessione.

al di là di questo, direi che varia.troppo in sessione in grado di rallentare se non si utilizza il processo di sessione, perché si sta andando ad essere la serializzazione molto di + la velocità del fornitore di servizi.Cache di Sessione e dovrebbe essere usato con parsimonia e attenzione.Non basta mettere in sessione, perché è possibile o non è conveniente.Sedersi e analizzare se ha senso.

Answer 4

Idealmente, la sessione in ASP deve memorizzare la quantità minima di dati che si può ottenere via con.Memorizzare un riferimento a un oggetto che è in possesso di risorse di sistema aperto (in particolare una connessione al database) è una certa scalabilità.Inoltre, la memorizzazione di commit in una variabile di sessione è solo una cattiva idea nella maggior parte dei casi.Nel complesso sembra che l'implementazione attuale è di utilizzare abusivamente gli oggetti di sessione per provare a simulare un stateful applicazione in un presunto ambiente stato.

Anche se è molto diffamato, il ASP.NET modello di gestione dello stato automaticamente attraverso i campi nascosti dovrebbe davvero eliminare la maggior parte della necessità di tenere nulla in variabili di sessione.

La mia regola è che più scalabile (in termini di utenti/hits) che l'app deve essere, meno si può ottenere via con l'utilizzo di stato della sessione.C'è, tuttavia, un trade-off.Per le applicazioni web in cui l'utente viene ripetutamente che accedono agli stessi dati e in genere ha una lunga sessione per l'uso del sito, alcuni di cache (se necessario in oggetti di sessione) può effettivamente aiutare la scalabilità, riducendo il carico sul server DB.L'idea qui è che è molto più conveniente e meno complesso di agriturismo il livello di presentazione di back-end su DB.Naturalmente, con tutte le cose, questo consiglio si dovrebbe prendere in moderazione e non si applica in tutte le situazioni, ma per una cosa abbastanza semplice da in-casa CRUD app, dovrebbe servire bene.

Answer 5

Un domanda molto simile è stato chiesto per quanto riguarda le sessioni di PHP precedenti.Fondamentalmente, le Sessioni sono un ottimo posto per memorizzare i dati specifici dell'utente che avete bisogno di accedere in diversi caricamento della pagina.Le sessioni NON sono un luogo ideale per memorizzare connessione al database di riferimenti;faresti meglio a utilizzare una sorta di pool di connessioni del software o di apertura/chiusura di una connessione su ogni caricamento di pagina.Quanto riguarda la memorizzazione dei dati nella sessione, questo dipende dalla sessione di archiviazione dei dati, quanto la sicurezza di cui avete bisogno, e se i dati specifici dell'utente.Una scommessa migliore sarebbe usare qualcos'altro per la memorizzazione di dati.

Answer 6

memorizzazione di navigazione spunti in sessioni è difficile.Lo stesso utente può avere più finestre aperte e quindi le modifiche vengono propagate in un modo confuso.DB connessioni sicuramente non verranno memorizzati.ASP.NET mantiene la connessione in piscina, non c'è bisogno di ricorrere alla propria stregoneria.Se avete bisogno di cache roba per brevi periodi e la dimensione del set di dati è relativamente piccolo, guardare in ViewState come una possibile opzione (al costo di un carico di più di massa sulla dimensione della pagina)

Answer 7

A:I dati che è solo relativa ad un singolo utente.Vale a dire:un nome utente, ID utente.A più un oggetto che rappresenta un utente.A volte URL-i dati relativi (come dove prendere qualcuno) o un messaggio di errore di stack sono utili per spingere in sessione.

Se si desidera condividere la roba potenzialmente tra i diversi utenti, utilizzare il negozio di Applicazioni o la Cache.Sono di gran lunga superiori.

Answer 8

Stefano,
Non si lavora per una società che comincia con "io", che ha un sito web che inizia con "BC"?Che suona esattamente come quello che ho fatto quando ho iniziato a sviluppare in .net (ed ero giovane e stupido) -- ho stipato tutto quello che avrei potuto pensare in sessione e l'applicazione.Inutile dire che è stato il doppio-plus ungood.
In generale, evitate di sessione, per quanto possibile.Certamente, non oggetti serializzabili non dovrebbe essere memorizzate (connessioni di database e così via), ma anche i grandi, oggetti serializzabili non deve essere.Tu non vuoi il sovraccarico.

Answer 9

Vorrei tenere sempre molto poco informazioni in sessione.Le sessioni di utilizzare il server di risorse di memoria, che è costoso.Risparmio di troppi valori in sessione aumenta il carico sul server e vedere le prestazioni del sito andrà giù.Quando si utilizza il bilanciamento del carico dei server, utilizzo di sessione può incorrere in problemi.Quindi quello che faccio è usare una minima o nessuna sessioni di utilizzare i cookie, se le informazioni non sono molto critica, utilizzare i campi nascosti più e sessioni di database.