Suivi des pages ouvertes avec ASP.Net

Question

Je suis sûr que cette question a déjà été posée, mais je ne la vois pas vraiment.

En utilisant asp.net et C#, comment suivre les pages qui sont ouvertes/fermées?

J'ai essayé toutes sortes de choses, y compris:

• modification des opérations l'application de fichiers global.asax/début de session/fin
• Réglage de destructor d'une page de rapport à l'application
• statique variables (qui persistent globalement plutôt que sur une base session par session)
• javascript window.onload et window.onbeforunload gestionnaire d'événements

Il a été éducatif, mais jusqu'à présent, aucune solution réelle n'a émergé.

La raison pour laquelle je veux faire cela est d'empêcher plusieurs utilisateurs de modifier la même table en même temps. C'est-à-dire, j'ai une liste de liens vers des tables, et quand un utilisateur clique pour modifier une table, je voudrais placer ce lien pour être verrouillé de sorte que AUCUN UTILISATEUR puisse alors modifier cette table. Si l'utilisateur ferme la page de modification de la table, je n'ai aucun moyen de déverrouiller le lien vers cette table.

Merci de votre lecture et de votre aide.

Answer 1

Vous ne devriez pas vous soucier du suivi des pages ouvertes ou fermées. Une fois qu'une page Web est rendue par IIS c'est aussi bon que "fermé".

Ce que vous devez faire est de protéger les utilisateurs de deux mettre à jour votre table en même temps en utilisant des verrous ... Par exemple:

using (Mutex m = new Mutex(false, "Global\\TheNameOfTheMutex")) 
    { 
      // If you want to wait for 5 seconds for other page to finish, 
      // you can do m.WaitOne(TimeSpan.FromSeconds(5),false) 

      if (!m.WaitOne(TimeSpan.Zero, false)) 
       Response.Write("Another Page is updating database."); 
      else 
       UpdateDatabase();        

    } 

Ce que ce fait est extrait ci-dessus, il ne permettra à aucun autre page Web pour appeler la méthode UpdateDatabase alors qu'une autre page exécute déjà l'appel UpdateDatabase. Ainsi, aucune page ne peut appeler updateatabase au même moment. Mais cela ne protège pas le second utilisateur de l'exécution de UpdateDatabase APRES la fin du premier appel, vous devez donc vous assurer que votre méthode UpdateDatabase dispose des vérifications appropriées, c.-à-d. il ne permet pas la mise à jour des données périmées.

Answer 2

Je pense que vous allez dans le mauvais sens sur ce ...

Vous devriez vraiment la manipulation de votre couche via votre concurrency d'affaires/db et ne pas compter sur l'interface parce que les gens peuvent et trouver un moyen de contourner ce que vous mettre en place.

Je vous recommande de stocker une «clé» dans votre page servie chaque fois que vous servez une page qui peut modifier la table. La clé est comme un tampon de versionnement de la dernière fois que la table a été mise à jour. Envoyez cette clé avec votre mise à jour et validez qu'elle correspond avant de procéder à la mise à jour. Si ce n'est pas le cas, alors vous savez que quelqu'un d'autre est venu et a modifié cette table et vous devez informer l'utilisateur qu'il y avait un conflit de concurrence, les données ont changé, et veulent-ils voir les nouvelles données.

Answer 3

Vous ne devez pas utiliser les demandes de page pour verrouiller les tables de base de données. Cela ne fonctionnera pas bien pour plusieurs raisons. Chaque requête crée un nouvel objet page, et il y a plusieurs contextes d'application, qui peuvent être sur plusieurs threads/processus, etc. Chacun d'entre eux peut tomber de la surface de la terre à tout moment. Le plus haut niveau de résolution de ce problème est de savoir pourquoi vous devez verrouiller les tables en premier lieu. Une manière courante d'éviter cela est d'accepter toutes les modifications de la table utilisateur et de permettre aux utilisateurs de résoudre leurs conflits.

Si le verrouillage est absolument nécessaire, vous pouvez utiliser une table de verrouillage qui est modifiée avant et après les modifications. Cette table devrait avoir un moyen d'expirer les verrous lorsque les utilisateurs s'en vont sans le faire.

Par exemple. Voir http://www.webcheatsheet.com/php/record_locking_in_web_applications.php C'est pour PHP mais le concept est le même.