Was ist wirklich in Sitzung in ASP.NET gespeichert?

Question

Wir versuchen zu entscheiden, wie die Objektpersistenz bei Postbacks gehandhabt wird, um zu vermeiden, dass die Daten aus der Datenbank bei jeder Anfrage abgerufen werden. Ich möchte Session verwenden (es handelt sich um eine Intranetanwendung, es werden nicht Tausende von Benutzern sein) , aber das ist aufgrund der Tatsache, dass ich vermute, dass nur der Verweis auf das reale Objekt dort gespeichert ist ...

Weiß jemand für eine Tatsache, wenn das wahr ist?

Ich habe immer gelernt, nicht über das Session-Objekt zu verwenden, aber wenn es so funktioniert wäre es nicht wirklich ein großes Problem sein ...

Was wirklich in Session gespeichert wird:

Session["myKey"] = myObject; 

Das eigentliche serialisierte Objekt oder seine Referenz?

Answer 1

Ich habe dies versucht:

Ich habe eine Klasse erstellt und speichert eine Instanz dies in der Sitzung (Sitzungszustandsmodus: InProc). Instanz lebt in aspnet_wp.exe proc.

Dann änderte ich den Sitzungszustand in SQL Server (noch ohne Attribut [Serializable]) und ich bekam die folgende Fehlermeldung.

Kann den Sitzungsstatus serialisieren. Im Modus 'StateServer' und 'SQLServer' serialisiert ASP.NET die Sitzungsstatusobjekte, und daher sind nicht serialisierbare Objekte oder MarshalByRef-Objekte nicht zulässig.

So gibt es keine Serialisierung für INPROC Sitzungszustand.

Prost ... Martín

Answer 2

ASP.NET erstellt eine GUID, die standardmäßig in einem Cookie gespeichert ist (Sie können jedoch die Verwendung der Querystring angeben), um den Benutzer zu identifizieren. Die diesem Cookie zugeordneten Objekte werden standardmäßig auf dem Server im IIS-Prozess gespeichert.

Sie können auch benutzerdefinierte Sitzungsobjektspeicher (Sitzungsstatusspeicheranbieter) erstellen, wenn Sie beispielsweise Sitzungsobjekte nicht verarbeiten möchten.

Mehr Infos hier:

http://msdn.microsoft.com/en-us/library/ms178587.aspx

Aber tatsächlich Ihre Frage zu beantworten ...

Out of the box, sind Sie in der Annahme richtig, dass die Session-Speicher speichert nur ein Verweis auf das Objekt.

Obwohl Sie das Speicherverhalten der Sitzungsfunktionalität in der web.config angeben können, glaube ich, auch Serialisierung zu erreichen. Die 3 Modi:

• InProc - Sitzung gehalten, wie Live-Objekte in Web-Server (aspnet_wp.exe). Verwenden Sie die "cookieless" -Konfiguration in web.config, um die sessionId auf die URL zu "munge" (löst auch Cookie-/Domänen-/Pfad-RFC-Probleme!)
• StateServer - Sitzung serialisiert und im Speicher in einem separaten Prozess gespeichert (aspnet_state.exe) . State-Server kann auf einem anderen Rechner laufen
• SQLServer - Sitzung serialisiert und gespeichert in SQL Server

Die oben ist aus: http://www.eggheadcafe.com/articles/20021016.asp

Answer 3

Es ist abhängig, was Sitzung, die Sie verwenden, wenn Sie inproc Sitzung mit in Sie haben Verfolgen Sie den Verweis in Sitzung, aber während es selbst verweist es nur eine Verbindung zu einem Objekt hält es das gesamte Objekt in den Prozess Speicher, so wenn Sie Ihre Anwendung entwerfen ist sehr wünschenswert zu wissen, wie viele Daten Sie pro Benutzer und wie viele haben aktive Benutzer haben Sie pro Stunde. Das Objekt innerhalb des Prozessspeichers wird nicht serialisiert, wenn Sie in der proc-Sitzung verwenden. Es wird jedoch serialisiert, wenn Sie eine out-of-proc-Sitzung verwenden. Es kann Implementierungen zur Leistung durchführen.

denke ich, hier gibt es sehr gut finden overview of session and cache

Answer 4

Es ist wichtig, sich daran zu erinnern, dass In-Proc Session-Daten ziemlich zerbrechlich ist ... was bedeutet es nicht, dass es sein kann, wenn Sie sie am meisten benötigen.Wenn der Worker-Prozess aus irgendeinem Grund recycelt poof ist es weg.

Answer 5

Ich verstehe, dass Sie im Moment nicht viele Leistungsbedenken haben und Sitzung würde wahrscheinlich gut funktionieren; Es gibt jedoch andere Möglichkeiten, den Status beizubehalten oder Daten über Postbacks hinweg zu transportieren.

Wenn Sie versuchen, Daten über Postbacks von der gleichen Seite beharren, dann würde ich stattdessen mit dem Viewstate empfehlen. Beachten Sie, dass in ViewState gespeicherte Daten serialisiert sind und jedes Objekt, das Sie persistieren möchten, ISerializable implementieren muss.

Answer 6

Es gibt Unmengen von Artikeln und Blog-Posts, die die Verwendung von Speichern komplexer Objekte bemängeln (technisch Verweise auf die Objekte zu speichern) in Session-Variablen. Im Allgemeinen denke ich, dass Sitzungsvariablen die Arbeit des Teufels sind und alles tun, um sie zu vermeiden.

Für eine Intranet-Deployed-App, in der der Entwickler die Auswirkungen von Session-Sessions auf die Skalierbarkeit versteht, wie Juan Manuel beschreibt, habe ich das schon oft und mit großem Erfolg getan. Ja, die Sitzung kann einen Recyle durchführen, aber das ist ein ungewöhnlicher Randfall - das tritt nicht regelmäßig genug auf, um Browser-Apps mit rationalem Sitzungszeitlimit zu beeinträchtigen.

Ich würde sagen, bauen Sie die App, wie Sie vorschlagen, Juan Manuel, zumindest auf den ersten. Aber entfernen Sie die Stelle, an der Sie Objekte speichern und von der Sitzung abholen (mit einer Wrapper-Klasse vielleicht), damit die Anwendung dies später leicht ändern kann.