N Configuring hibernation in a web farm

Question

Our current project at work is the new MVC website that will use the WCF service, primarily to access third-party billing systems through the web service, as well as a small SQL database to personalize users. The WCF service uses nHibernate for an SQL database.

We would like to implement some kind of web farm for load balancing, as well as recovery and maintenance. I am trying to solve the best way to handle caching of nHibernate and concurrency database if there are multiple WCF services.

Some scenarios I was thinking about ...

1) Several IIS servers, one WCF server. With this setting, the WCF server will be the only point of failure, but there will be no problems with caching nHibernate or the concurrency database.

2) Several IIS servers, each of which has its own WCF service. This removes one point of failure, but now nHibernate on one machine will not be aware of database changes made by another machine.

Some solutions for number 2 will use IStatelessSession, so we do not cache, and nHibernate is always fetched directly from the database. This may be the most feasible, since our personalization database contains very few objects. I also consider second-level cache, such as memcached or Velocity, but it might be redundant for this system.

I talk about this to find out if anyone has experience with this kind of architecture and get some ideas for a solution. Thanks!

Answer 1

Something is missing me, I do not see a problem with nhibernate on web servers. The application cache will not be a problem, since each nhibernate block will store its own cache, which will be populated from the data store. look at creating a table that can be checked for the reasons necessary to update the cache. we used this, using the CacheDependency class in .net 2.0, which would detect changes in the column and then remove the corresponding item from the cache. therefore, if the user inserts a new product, the cache will be deleted, and the next call to get the products will load the cache again. it is old, but check: http://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2 for this concept. greetings

Answer 2

I would advise against caching until caching is a problem. Your database will do its own caching so that you repeatedly look for the same data, so the only thing you need to worry about is posting data. Judging by your description, you will not have a problem. If you ever get to the scene where you work, use the distributed cache - allowing servers to be cached separately, this will cause problems with updating data during the update.