J'ai des difficultés à obtenir 2 applications identiques ASP.NET MVC pour partager la même session à l'aide d'une session d'État d'État. La raison pour laquelle j'essaie de faire cela est que nous déployons éventuellement l'application de cette application sur 3 serveurs Web qui doivent partager le même État. Nous devons utiliser STATEERVER, car nous essayons de minimiser l'utilisation de la DB pour un stockage non liée aux données.
la configuration: stry> p> J'ai déployé la même base de code to http: // localhost / app1 strong> et http: // localhost / app2 fort> p> Les deux ont des fichiers Web.config identiques avec les éléments suivants: P> <p>
Mode: <%= ViewData["mode"].ToString() %>
</p>
<p>
Time: <%= ViewData["timestamp"].ToString() %>
</p>
<p>
real time: <%= ViewData["realtime"].ToString() %>
</p>
4 Réponses :
Par défaut Session ne peut pas être partagé entre différentes applications. De ce que je peux voir, vous avez deux applications distinctes Comme toujours, il y a Solution de contournement que vous pouvez trouver utile. Comme vous pouvez le constater, il utilise un hack (réflexion) pour contourner la détermination de l'équipe ASP.NET pour ne pas exposer certaines classes et propriétés et rendre notre vie en tant que développeurs difficiles. app1 et app2 qui exécutent des répertoires virtuels distincts et probablement même des pools d'applications distincts, alors ne vous attendez pas à partager la session entre elles .
Vous avez raison qu'ils sont des applications distinctes. On existe dans D: \ APP1 et l'autre est dans D: \ APP2 et sont dans différents répertoires virtuels sous WeyWebSite dans IIS. Cependant, les deux sont en cas de défaillance. La raison en est que nous allons éventuellement déployer cette application sur 3 serveurs Web qui doivent partager le même État.
Je pense que c'est le répertoire virtuel qui détermine le nom de l'application et non le pool de candidatures, je suppose donc que vous devrez recourir au piratage qui oblige le même nom de demande.
Ok, je vais prendre cela en considération. Si nous finissons à suivre la voie des hacks pour atteindre ce résultat, je pense que nous pourrions être préférable de rester mieux avec la base de données pour stocker la session. L'approche DB semble être plus robuste de toute façon.
Désolé de vous décevoir, mais même si vous prenez la solution de base de données, vous devrez recourir à des hacks: blogs.msdn.com/b/toddca/archive/2007/01/25/... Il n'y a pas d'absence de -Le façon de partager la session entre les applications dans ASP.NET. La session Out-of-PROC est utile lorsque vous avez la même application dans une ferme serveur. Pour différentes applications, vous examinerez probablement un moyen plus standard de partage de données (obtenir, poster des demandes).
Je pense juste .. Vous avez dit que c'est le répertoire virtuel qui détermine le nom de l'application. Cette application sera déployée sur 3 serveurs Web, chacun d'entre eux aura le même nom de site Web dans leur IIS respectif, avec un équilibreur de charge fractionnant la charge entre eux. Cela se qualifierait-il comme ayant le même nom d'application? Pensez-vous que cela fonctionnerait dans un environnement comme ça?
Non, cela ne sera pas qualifié de même application.
Ok, merci pour les informations sur ce sujet. Je pense que nous devrons penser à la façon dont nous allons faire cela.
Mise à jour: Voici un article précédent que j'ai répondu sur ce même sujet Partage de sessions entre les applications à l'aide de la session ASP.NET Service d'état
Comme déjà signalé, les données de session sont scopées à l'application. C'est l'application que vous créez dans IIS. Donc, deux applications avec le même identifiant de session ne partageront pas la même session en raison de la portée de l'application.
comme une autre idée qui pourrait ou pourrait ne pas être réalisable pour vous.
Vous pouvez créer une application racine et avoir le code pour D: \ app1 et d: \ app2 dans deux sous-dossiers. puis dans IIS, vous créez une application pointant sur D: \ Root. Vous pouvez également créer une application dans IIS, puis sous l'application, vous créez deux répertoires virtuels, l'un pointant vers D: \ app1 et l'autre à D: \ app2, alors ils peuvent également partager Un seul de sorte que votre mise en page de disque dur pourrait ressembler à quelque chose comme ça Créer l'application racine pointant vers D: \ racine puis sous l'application crée les deux virtuels répertoires App1 pointant vers D: \ app1 et app2 pointant vers D: \ app2. L'effet dans les deux cas est que vous avez une seule application divisée en deux sections, à la fois dans la même portée du code. pour les deux peuvent partager les mêmes données de session. web.config au niveau de l'application. Il est essentiel que les deux répertoires virtuels ne soient que virtuels et non créés comme applications.
Vous devez également vous assurer que le chemin d'application de l'application doit être identique sur les deux serveurs Web. Il y a un ancien article ici qui pourrait aider
http://support.microsoft.com/default .aspx? scid = kb; en-nous; Q325056
Nous rencontrons actuellement un problème similaire, sauf que nous utilisons IIS 7.5 et les chemins d'application sont cachés à nous (n'utilise plus la métabase). Est-ce que quelqu'un connaît une façon de dépanner cela avec IIS 7.5?
À mon avis, je pense que Microsoft a laissé tomber la balle avec IIS au cours des dernières deux versions.
En réalité, vous pouvez partager des sessions à l'aide du mode SQL Server.
Essayez ceci: - p>
Je viens de modifier la procédure, c'est-à-dire P>
<sessionState mode="SQLServer" sqlConnectionString="Data Source=.;Integrated Security=True;Application Name=TEST" cookieless="false" timeout="20"></sessionState> <httpRuntime targetFramework="4.5"/>
Non seulement cela a fait ce travail, c'est la mise en œuvre la plus facile de loin. Merci!
Assurez-vous également que vos touches de machine et vos identifiants d'applications sont les mêmes. blogs.msdn.microsoft.com/httpcontext/2012/06/22/...
Avez-vous pu compléter cela?
@DaveDev Je sais que je suis en retard à la fête: P, mais cela pourrait aider les autres. Si vous pouviez trouver le même domaine pour la session Cookie (voir msdn.microsoft.com/en-in/library/ms228262 (v = vs.85) .aspx ) et session de stocker au service commun (DB / REDIS), vous pouvez absolument partager la session entre plusieurs serveurs.