IRequiresSessionState vs IReadOnlySessionState

Quelle est la différence entre IRequiresSessionState et IReadOnlySessionState l’incapacité de la seconde d’enregistrer les modifications apscopes aux variables de session?

Les deux me permettent d’accéder aux variables de session dans mon HttpHandler . Mais pourquoi devrais-je préférer IReadOnlySessionState ? Cela me empêche simplement de sauvegarder la session pour la prochaine demande.
Ou est-ce que cela me donne un avantage de performance par rapport à IRequiresSessionState ?

Quand préférerais-je utiliser IReadOnlySessionState plutôt que IRequiresSessionState ?

Une différence critique réside dans le fait qu’IRequiresSessionState met un verrou exclusif sur la session en cours, limitant ainsi potentiellement le nombre de demandes simultanées de l’utilisateur actuel. (Pour plus d’informations sur ce phénomène de locking, voir Est-il possible de forcer l’access simultané à des requêtes lors de l’utilisation de sessions ASP.NET? )

En revanche, IReadOnlySessionState n’acquiert pas de verrou exclusif.

C’est la même chose documentée dans la réponse utile de Renad à une question SO à peu près identique .

La meilleure documentation officielle que j’ai trouvée à ce sujet provient d’un article MSDN intitulé Fournisseurs d’état de session :

Les trois méthodes les plus importantes d’un fournisseur d’état de session sont GetItem, GetItemExclusive et SetAndReleaseItemExclusive. SessionStateModule appelle les deux premiers pour extraire une session de la source de données. Si la page demandée implémente l’interface IRequiresSessionState (par défaut, toutes les pages implémentent IRequiresSessionState), le gestionnaire d’événements AcquireRequestState de SessionStateModule appelle la méthode GetItemExclusive du fournisseur d’état de session. Le mot “Exclusive” dans le nom de la méthode signifie que la session ne doit être extraite que si elle n’est pas utilisée par une autre requête. Si, en revanche, la page demandée implémente l’interface IReadOnlySessionState (le moyen le plus courant d’y parvenir consiste à inclure un atsortingbut EnableSessionState = “ReadOnly” dans la directive @ Page de la page), SessionStateModule appelle la méthode GetItem du fournisseur. Aucune exclusivité n’est requirejse ici, car les access en lecture qui se chevauchent sont autorisés par SessionStateModule.

Notez le parallèle entre l’utilisation explicite de ces interfaces et l’utilisation de la directive EnableSessionState Page:

EnableSessionState = False <-> pas d’interface I * SessionState
EnableSessionState = True <-> Interface IRequiresSessionState
EnableSessionState = ReadOnly <-> IReadOnlySessionState

Cette interface contrôle si la structure sauvegardera l’état de la session en cours à la fin de la requête. Cela fait une plus grande différence lorsque vous utilisez le stockage d’état de session hors processus. Dans ce cas, sans l’interface, le système stockera toujours les données de session dans la firebase database distante, même si elles n’ont pas été modifiées (le système ne garde pas trace du fait de savoir si les données de session ont été modifiées lors de la demande). Lorsque vous utilisez l’interface IReadOnlySessionState, la phase de réécriture est ignorée.

Suivez cette http://msdn.microsoft.com/en-us/library/system.web.sessionstate.irequiressessionstate.aspx

IRequiresSessionState est dérivé de System.Web.SessionState en utilisant cette interface, nous accédons à la session dans Httphandler et le fichier de classe

Si vous avez besoin d’un access en lecture seule à la session, implémentez l’interface IReadOnlySessionState.