Je viens de découvrir que chaque demande dans une application Web ASP.Net obtient un verrou de session au début d'une demande, puis le libère à la fin de la demande!
Au cas où les implications de cela seraient perdues pour vous, comme c'était le cas pour moi au début, cela signifie essentiellement ce qui suit:
Chaque fois qu'une page Web ASP.Net prend beaucoup de temps à charger (peut-être en raison d'un appel lent à la base de données ou autre), et l'utilisateur décide qu'il souhaite naviguer vers une autre page parce qu'il est fatigué d'attendre, IL NE PEUT PAS! Le verrou de session ASP.Net force la nouvelle demande de page à attendre que la demande d'origine ait terminé son chargement douloureusement lent. Arrrgh.
Chaque fois qu'un UpdatePanel se charge lentement, et l'utilisateur décide de naviguer vers une autre page avant la fin de la mise à jour du UpdatePanel ... IL NE PEUT PAS! Le verrou de session ASP.net force la nouvelle demande de page à attendre que la demande d'origine ait terminé son chargement douloureusement lent. Double Arrrgh!
Quelles sont donc les options? Jusqu'à présent, j'ai trouvé:
- Implémentez un SessionStateDataStore personnalisé, pris en charge par ASP.Net. Je n'en ai pas trouvé trop à copier, et cela semble assez risqué et facile à gâcher.
- Gardez une trace de toutes les demandes en cours et, si une demande provient du même utilisateur, annulez la demande d'origine. Semble un peu extrême, mais cela fonctionnerait (je pense).
- N'utilisez pas Session! Lorsque j'ai besoin d'une sorte d'état pour l'utilisateur, je peux simplement utiliser le cache à la place et les éléments clés sur le nom d'utilisateur authentifié, ou quelque chose de ce genre. Cela semble encore un peu extrême.
Je ne peux vraiment pas croire que l'équipe ASP.Net Microsoft aurait laissé un goulot d'étranglement de performances aussi énorme dans le cadre de la version 4.0! Suis-je en train de manquer quelque chose d'évident? À quel point serait-il difficile d'utiliser une collection ThreadSafe pour la session?