Class singleton d'une portée applicative et non au niveau de la session

Version imprimable

17/12/2010, 15h36
titan_33

Class singleton d'une portée applicative et non au niveau de la session

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
17/12/2010, 16h04
lutecefalco

Je confirme
17/12/2010, 18h44
Nicolas Esprit

Je confirme aussi :mouarf:

Tu peux faire un truc comme ça :

Code:

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;
    }
}

17/12/2010, 22h22
Nathanael Marchand

Ca implique que l'objet soit sérialisable non?
17/12/2010, 23h17
tomlev

Citation:

Envoyé par PitMaverick78

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é :

Citation:

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
20/12/2010, 14h04
Bluedeep

Citation:

Envoyé par PitMaverick78

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.
20/12/2010, 14h14
Nathanael Marchand

Je disais ca car dans les différents projets pro en asp.net sur lequels j'ai travaillé, on travaillé avec les sessions en base SQL. On avait rencontré quelques soucis justement.
Est ce que c'était le meilleur choix? Aucune idée :D
20/12/2010, 14h21
Bluedeep

Citation:

Envoyé par PitMaverick78

Je disais ca car dans les différents projets pro en asp.net sur lequels j'ai travaillé, on travaillé avec les sessions en base SQL. On avait rencontré quelques soucis justement.
Est ce que c'était le meilleur choix? Aucune idée :D

Mais c'est un excellent choix, pas de soucis. :D

Ce que je décrits supra est une solution de contournement, mais de contournement d'un problème lié à un défaut de conception a priori (cas d'infos d'état qui sont elle même "statefull" ce qui est une anomalie en soi).
20/12/2010, 18h09
mermich

Salut,

D'autres solutions existent: tu créer un dictionnaire statique ayant comme clé l'identifiant de l'utilisateur connecté et en valeur ton objet.

La solution de tomlev est mieux car en termes de stockage, lorsqu'un utilisateur voit se session terminée, l'instance stockée est vidée (et non gardée inutilement dans ma solution).
20/12/2010, 18h12
Bluedeep

Citation:

Envoyé par mermich

D'autres solutions existent: tu créer un dictionnaire statique ayant comme clé l'identifiant de l'utilisateur connecté et en valeur ton objet.

Ca ne règle pas le problème de sérialisation en load balancing.

Citation:

La solution de tomlev est mieux car en termes de stockage, lorsqu'un utilisateur voit se session terminée, l'instance stockée est vidée (et non gardée inutilement dans ma solution).

Absolument pas nécessaire de garder quoique ce soit car il suffit de détruire les références dans le code de l'event Session_End.

Mais ça ne change rien au problème soulevé ci-dessus : ce type de solution n'est valable qu'en noeud unique, donc non "scalable".