Discussion :

[titan_33]

Bonjour

J'ai une "Class singleton" sur un site Web, et je viens de constater que sa portée est au niveau applicatif, c'est à dire que toutes les personnes sur le site ont la même valeur.
Je pensais que la protée était au niveau de la session, soit unique pour chaque internaute.

Pouvez-vous me confirmer mon diagnostique.

Merci à vous.

Titan

[lutecefalco]

Je confirme

[Nicolas Esprit]

Je confirme aussi

[tomlev]

Tu peux faire un truc comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public static MySingleton Instance
{
    get
    {
        MySingleton instance = (MySingleton)HttpContext.Current.Session["MySingleton"];
        if (instance == null)
        {
            instance = new MySingleton();
            HttpContext.Current.Session["MySingleton"] = instance;
        }
        return instance;
    }
}

[Nathanael Marchand]

Ca implique que l'objet soit sérialisable non?

[tomlev]

Ca implique que l'objet soit sérialisable non?

Possible, je suis pas expert en ASP.NET... ça dépend peut-être de ce que tu utilises pour le stockage des sessions, non ? Je ne pense pas que les sessions en mémoire (InProc) soient sérialisées... enfin je sais pas trop en fait. La doc ne dit rien à ce sujet (ou alors j'ai pas trouvé)

EDIT: ah si, j'ai trouvé :

Lorsque vous utilisez un mode d'état de session autre que InProc, le type session-variable doit être d'un type .NET primitif ou sérialisable. Ceci car la valeur de variable de session est stockée dans un magasin de données externe. Pour plus d'informations, consultez Modes d'état de session

[Bluedeep]

Ca implique que l'objet soit sérialisable non?

Concrétement, tu peux te dispenser de la possibilité de sérialiser les objets de session si tu n'utilises pas de load balancer.

Même dans ce cas, tu peux quand mêle utiliser un session state InProc à condition que le routeur qui se charge du load balancing soit paramètré "finement" pour traiter l'ensemble des requêtes concernant une session vers le même noeud.

En revanche, dès l'instant où tu veux traiter les différentes requêtes au sein d'une session sur des noeud différents, il faut que les objets de sessions soit sérialisables.

A part cela, on peut toujours trouver des astuces de contournement mais un peu lourdes; par exemple, garder en session une clef d'identification d'objet récupérable depuis un service externes aux noeuds de traitement IIS et accessibles par chacun des noeuds : le problème étant que tu ne peux pas dans ce cas avoir de tolérance de faute sur ce service, car sinon, il faut pouvoir gérer la sérialisation des objets maintenus par ce service (donc, ça se mord un peu la queue).

Bref, dès l'nstant où tu veux avoir des infos d'état non sérialisables sur une session, cela devient "touchy". Une solution peut être de sérialiser les infos permettant de reconstituer ces objets non sérialisables.