Une variable stockée dans Session est-elle désérialisée une ou plusieurs fois pendant le cycle de vie d'une page?

Question

Je voudrais envelopper les variables de session d'une manière similaire à celle discussed on CodeProject.

public static class WebSession 
{ 
    private const string CurrentUserKey = "CurrentUser"; 

    private static HttpSessionState Session 
    { 
    get { return HttpContext.Current.Session; } 
    } 

    public static bool Exists 
    { 
    get { return Session != null; } 
    } 

    public static User CurrentUser 
    { 
    get { return Session[CurrentUserKey] as User; } 
    set { Session[CurrentUserKey] = value; } 
    } 
} 

Voici ma question: si je dois accéder CurrentUser plusieurs fois dans la même page, pourrais-je obtenir une amélioration de la performance en attribuant à une variable locale au lieu d'accéder à la propriété d'emballage? Ou le HttpSessionState s'assure-t-il que l'objet n'est désérialisé qu'une seule fois par requête, de sorte que les appels suivants dans la même requête http ne coûtent plus?

Merci, Aaron

Answer 1

Il y a une copie en mémoire de votre état de session sur chaque demande. Par conséquent, le seul coût que vous pourriez enregistrer en copiant localement une variable de session est celui de la conversion d'Objet en votre type. La copie en mémoire est ensuite ajoutée à la session à la fin de la demande.

Que la session soit sérialisée ou désérialisée sur une page dépend du fournisseur de session que vous choisissez. Pour l'état de session In-Proc, aucune sérialisation ne se produit. Pour les serveurs de session, l'objet doit être sérialisé en premier.

Answer 2

quelques bons articles à lire

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

http://msdn.microsoft.com/en-us/magazine/cc163730.aspx#S5

Answer 3

J'ai fait un peu de travail en séparant la session recently, et d'après ce que j'ai pu voir, l'objet état entier est désérialisé une fois et une seule fois par demande. Bien sûr, il est assez facile de vérifier - il suffit de l'extraire deux fois et de vérifier ReferenceEquals. Bien sûr, placer la valeur dans un champ entre les utilisations permettrait d'économiser du temps de "recherche", mais vous ne devriez payer le coût de désérialisation qu'une seule fois.

Si vous vraiment voulez être sûr, vous pouvez également revérifier cela en mettant en œuvre ISerializable et la consignation des appels sérialiser/désérialiser.

Answer 4

Il existe une copie en mémoire. Vous obtenez une amélioration des performances négligeable de la mise en cache de la valeur; cela ne sauverait qu'une recherche dans le Dictionnaire, ce qui serait trop rapide pour être remarqué, sauf si vous le faites une dizaine de fois par chargement de page.

Il est également important de noter que pour une clé donnée, chaque récupération renvoie une référence à la même instance et Session conserve également une référence. Cela signifie que si vous récupérez un objet de Session et le modifiez, vous n'avez plus besoin d'appeler le setter pour le re-sérialiser.

Je viens de poser une question sur ce même chose: Are .Net property setters ever called implicitly?