stratégies NHibernate dans une ferme web

Question

Notre projet en cours au travail est un nouveau site Web MVC qui utilisera un service WCF principalement pour accéder à un système de facturation 3ème partie via un service Web ainsi qu'une petite base de données SQL pour la personnalisation de l'utilisateur. Le service WCF utilise nHibernate pour la base de données SQL.

Nous aimerions implémenter une sorte de batterie de serveurs Web pour l'équilibrage de charge ainsi que le basculement et la maintenance. J'essaie de décider de la meilleure façon de gérer la mise en cache et la concurrence de base de données de nHibernate si plusieurs services WCF sont en cours d'exécution.

Certains scénarios que j'ai pensé à ...

1) Plusieurs serveurs IIS, un serveur WCF. Avec cette configuration, le serveur WCF serait un point de défaillance unique, mais il n'y aurait aucun problème avec la mise en cache nHibernate ou la concurrence d'accès à la base de données.

2) Plusieurs serveurs IIS, chacun avec son propre service WCF. Cela supprime un seul point de défaillance, mais maintenant nHibernate sur une machine ne serait pas au courant des modifications de base de données effectuées par une autre machine.

Quelques solutions au numéro 2 serait d'utiliser un IStatelessSession donc nous ne pas faire de la mise en cache et NHibernate est toujours aller chercher directement à partir de la base de données. Cela pourrait être le plus faisable car notre base de données de personnalisation contient très peu d'objets. Je considère également un cache de second niveau tel que memcached ou Velocity, mais il est peut-être exagéré pour ce système.

Je suis en train de ce là-bas pour voir si quelqu'un a une expérience à faire ce genre d'architecture et d'obtenir quelques idées pour une solution. Merci!

Answer 1

me manque ici quelque chose que je, je ne vois pas de problème avec NHibernate sur les serveurs Web. le cache de l'application ne poserait aucun problème, car chaque boîte nhibernate conserverait son propre cache qui serait rempli à partir du magasin de données. regardez la création d'une table qui peut être surveillée pour des raisons d'actualisation du cache. nous avions l'habitude de faire cela en utilisant la classe CacheDependency dans .net 2.0 qui permettrait de détecter les modifications apportées à une colonne, puis de supprimer l'élément concerné du cache. Ainsi, si un utilisateur insère un nouveau produit, le cache sera supprimé et l'appel suivant pour obtenir les produits chargera à nouveau le cache. c'est vieux mais vérifiez: http://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2 pour le concept. acclamations

Answer 2

Je suggère de ne pas faire de mise en cache avant de ne pas faire de mise en cache devient un problème. Votre base de données effectuera sa propre mise en cache pour vous éviter de rechercher les mêmes données à plusieurs reprises, de sorte que la seule chose dont vous devez vous soucier est les données à travers le réseau. A en juger par votre description, vous n'allez pas avoir de problème là-bas. Si jamais vous en arrivez à une étape, utilisez un cache distribué - en permettant à vos serveurs de se mettre en cache séparément, vous risquez de faire rebondir les problèmes de données lors de l'actualisation.