abaudouin84
Messages postés10Date d'inscriptionlundi 16 mars 2009StatutMembreDernière intervention 3 novembre 2009
-
23 avril 2009 à 14:59
cs_coq
Messages postés6349Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention 2 août 2014
-
25 avril 2009 à 19:19
Bonjour,
Voilà j'ai une question niveau débutant sur la notion de "static" en asp.net.
Est-ce que la valeur d'une propriété statique dans une classe d'une DLL est partagée par tous les utilisateurs connectés au site ou seulement à "l'environnement" d'un seul utilisateur ?
Veuillez m'excuser de poser une question aussi c... mais j'ai un gros doute et je me demande si un problème que je rencontre n'est pas lié à cela.
krimog
Messages postés1860Date d'inscriptionlundi 28 novembre 2005StatutMembreDernière intervention14 février 201549 23 avril 2009 à 16:06
Salut
Je suis sûr à 90% qu'une propriété "static" est partagé entre tous les utilisateurs.
Si tu cherches à sauvegarder des données pour chaque utilisateur, tu peux utiliser :
Session[] => Sauvegardé sur le serveur / Commun à toutes les pages
ViewState[] => Passe du serveur au client et vice versa / Spécifique à une page
Cookie[] => Sauvegardé chez le client / Commun à toutes les pages
Et pour les variables communes à tous les utilisateurs :
Application[]
Krimog : while (!(succeed = try())) ;
- Quand le règlement tu respecteras, ravis de te répondre on sera -
krimog
Messages postés1860Date d'inscriptionlundi 28 novembre 2005StatutMembreDernière intervention14 février 201549 23 avril 2009 à 17:11
@Bidou : On ne peut pas lui en vouloir. Il s'agit effectivement d'une question relative à ASP.net, cependant il s'agit d'une DLL (donc pas liée avec une page aspx) en C#.
Cette confusion est bien plus excusable que 99% des erreurs dans le choix du forum ;-)
(Bon, après, c'est sûr que c'est mieux de poster sur www.aspfr.com)
Krimog : while (!(succeed = try())) ;
- Quand le règlement tu respecteras, ravis de te répondre on sera -
cs_Bidou
Messages postés5487Date d'inscriptiondimanche 4 août 2002StatutMembreDernière intervention20 juin 201361 23 avril 2009 à 17:42
krimorg> Oui, mais csharpfr est plus conçu pour les applications cliente, tandis que ce qui touche au web est pour aspfr...
Qu'il poste sur csharpfr ne me dérange pas du tout, mais je pense qu'une grosse partie des membres étant sur ce site connaissent mieux les app. clientes donc il aura plus de chance pour ces questions (futures) en postant là-bas ;-)
cs_coq
Messages postés6349Date d'inscriptionsamedi 1 juin 2002StatutMembreDernière intervention 2 août 2014101 25 avril 2009 à 19:19
Bonjour,
Concernant le sujet de la propriété static en elle même, hors du contexte web, c'est un peu plus compliqué que ça.
Le problème ne se situe pas au niveau du fait que la propriété soit static mais au fait qu'elle utilise un champs static.
Une propriété d'instance utilisant un champs static posera exactement le même problème.
Et la portée de la valeur d'un champs static est le domaine d'application (AppDomain), y compris pour les assemblies chargées de manière "domain neutral" (je ne sais pas trop comment traduire celà en français tiens) pour lesquels les champs static sont de toute façon séparés pour chaque AppDomain se servant du code chargé de manière commune.
Dans le contexte de l'hébergement d'une application web dans IIS, ça veut dire que la valeur sera partagée par tous les utilisateurs d'une instance de l'application web (sauf changement de comportement par l'hote du CLR, mais je ne sais même pas si ce genre de chose peuvent être modifiées par l'hote).
Si une seconde instance de l'application existe dans un second AppDomain (qu'il se situe dans le même worker process (w3wp etc) ou non), les utilisateurs dont les demandes sont traitées par cette seconde instance ne devraient pas voir la même valeur que les utilisateurs de la première
Les requêtes étant en général traitées par des threads issus d'un/des pool(s) de threads, on peut oublier l'utilisation l'attribut ThreadStatic.
Et concernant l'attribut ContextStatic, je ne suis pas certains qu'il ai un impact réel avec les contextes ASP.NET, à voir avec nos amis compétents dans le domaine.