I’ve been deploying BE.N to single servers for quite some time for many different clients.  All is well.  Depending on the client, the content is stored in the file system (xml documents) or in SQL Server.  Recently, a high volume client, required redundancy.  The solution hardware architecture is shown below:

My process started out similar to a process I use for web solutions.  Below is the process with a diagram showing the deployment.

• Update BE.N and settings on the development server.
• Publish BE.N to a client work area to update content (single server).
• Backup the App_data folder (content) and put in source control.
• Promote the BE.N solution with App_Data folder to Prod (cluster).

For the first deployment, it worked just like single node deployments.  Both nodes were up and running serving many connections.

Then a few content updates were required.  I followed the process as defined above.  The client gave me the call that the content was ready.  I backed it up and began the code promotion to production.

Here is where I ran into an issue.  One node was drained stopped, stopped the web site, copied the App_Data Folder over, and restarted the site.  On first inspection, the website still displayed the old content.  After a few spins around the brain on what could be happening, the site was using the cached version.  Ahhhh, the application pool wasn’t restarted.  Restarted the app pool and all was well.  So restart the site and the associated app pool.

Well, this causes another issue.  to restart the app pool, you need to stop accepting new connections to the node and wait for all customers to complete.  This could take up to 30+ minutes… depending on the shopper.

So, back to the situation, you download your XML file, edit what you need … and after you upload it back to its place you notice that the content remains the same when viewing it in the browser. This is due to the fact that BE.N is heavily caching content for you to have an almost instance response when you access the website. This is an awesome technique which definitely does not need to be changed, but we can find a little workaround so we can clear the cache whenever we want to?

Stay tuned, in my next post (after I run it through an actual deployment) I will write up how to clear the cache without starting/stopping the app pool.  Benefit – you don’t need to wait for all customers to leave and you don’t drop their session by restarting the app pool. 

Update: BE.N on the cluster (farm) is running very well and the access time is great due to the caching.  Having a repeatable solution is helping me learn all the ins/outs of using a product – compared to learning/understanding 1-off custom built solutions for each client.  Plus – controls, widgets, and techniques build for one client can be reused for all. 

Thank You for listening.