Préserver ASP.NET session InProc lorsque le processus W3WP (IIS) Recycle

Question

Je comprends que toutes les données de session est toujours InProc disparu lorsque son processus propriétaire w3wp recycle comme il se trouve que dans la mémoire w3wp.

Je me suis demandé si, s'il est possible de mettre en cache les données de session lors du recyclage se produit quelque part à l'extérieur du processus, puis réinjection (et reconstruction) la session quand il remonte. De cette façon, je rentrais à la vitesse de InProc avec la fiabilité du serveur extériorisation comme état si nécessaire. Est-ce possible?

Answer 1

Non, cela est impossible. Il n'y a pas d'API pour « réchauffer » en cours état de session ou le cache. Une telle solution serait peu fiable de toute façon. Vous ne pouvez gaurantee que la dernière chose que votre application ne serait d'exporter son état actuel de la session, de sorte que vous ne pourriez jamais compter sur les données importées pour être courant de toute façon.

Vous pouvez utiliser l'état hors proc serveur sur le même hôte que votre application Web. Ensuite, l'application Web peut recycler librement, en gardant les informations d'état intact. Ceci est tout à fait un peu plus rapide que d'utiliser SQL Server pour gérer les sessions, que vous ne devez pas traiter avec les frais généraux de transit SQL ou d'un réseau à une autre machine, la seule façon dont il est l'état de session pire que en cours est que les données doivent maréchal à travers les frontières du processus, mais aussi longtemps que vous ne disposez pas d'une énorme quantité de données de session en évolution rapide, cela ne devrait pas être perceptible à tous.

Il y a aussi d'autres alternatives, telles que Microsoft Code du projet nommé "Velocity" ou ScaleOut Logiciel SessionServer de (entre autres, je suis sûr) qui offrent des mécanismes de mise en cache distribuée qui peuvent garder l'état de session ou le cache synchronisé entre les serveurs dans une batterie de serveurs sans avoir à recourir à l'utilisation de SQL server.

Contrairement à ce qu'un autre utilisateur a posté, je ne voudrais pas utiliser ViewState pour stocker les données de session si possible. D'une part, il n'est pas vrai état de session, si un utilisateur se déplace en arrière ou transmettre, il peut être perdu. En second lieu, il est assez précaire. En troisième lieu, il provoque la météorisation page massives en cas d'abus.

Answer 2

Peut-être que vous pouvez stocker suffisamment d'informations dans un cookie (ou ViewState) afin que vous puissiez recréer une session sur la base de ces données dans le cas où le processus de travail a été recyclé.

Ou vous pouvez créer votre propre serveur d'état (par exemple un service de fenêtres) où vous stockez partie de votre session et accéder à ce service à partir de l'application Web via Remoting ou similaire.

Answer 3

Vous devez utiliser le serveur SQL pour l'état de session si c'est votre intention. Ce que vous voulez des séances qui peuvent se remettre d'une fin complète du traitee hôte. Ni inproc ou StateServer soutiennent que dès qu'ils descendent, ils perdent toutes les données. Vous pouvez écrire votre propre méthode d'état, mais ce serait laboriuous. Voici les directions si vous voulez faire:

http://www.exforsys.com/tutorials/asp.net-2.0/asp.net-2.0-customizing-the-session-state-mechanism.html

Ce que vous pouvez faire est pas utiliser des sessions du tout, mais plutôt appuyer davantage sur ViewState. Si vous avez un site à fort trafic qui est une bonne façon de pousser la charge de travail hors aux clients.