Single instance of windows service querying multiple databases

Question

My current situation is that we have four instances of a single windows service running on the server, for production, demo, QA and dev. I am looking for a solution where I just need to run single instance of the service that will hit all the above mentioned databases and process the data.

I know the purpose of having multiple databases (QA, dev etc.) is to do through testing and so I might have to install more than one instances. I am willing to install couple of instances (which is still less than 4 ) so that the maintenance is less.

But is there a way that a single windows service will do some sort of round robin technique and hit one database, do the processing, then hit the another database, do the processing and so on.

Answer 1

If your only goal is to reduce maintenance efforts, I suggest instead of making such a major architectural change to your service, add some tools which allow you to manage the four instances "as one". For example:

• starting and stopping of all four instances at once: can be accomplished by start and stop scripts

• backing up any data written by your services: just the same, some scripts will do it

• producing one log instead of many: make sure your services use standard windows logging mechanics which pipes all logging output of different processes into the standard system or application log

• using just one configuration file for all four services instead of four files: put parameters like the DB connection (which must be different for your four use cases) into different sections for QA, dev, test, production inside the configuration file, and separate those from parameters which are the same for all instances. Or, keep using different config files and provide an include mechanism to import config parameters equal for all instances from a shared file.

• and if your services need more maintenance tasks, you could even bundle that by creating a special management tool, maybe a command line tool, maybe a tool with a GUI, which makes the maintenance easier.

I guess that will be less effort than merging all the instances into one, and still leaves you in a position with all the benefits you have from four different instances now, like starting and stopping them individually, providing different versions of your program for testing and production, making sure a crash of the testing instance does not affect production, and so on.

Answer 2

Windows service is just a host for your application.

I may choose to write an application and host it in IIS process, or windows service, or console application, or WPF application. Point I'm making is that it does not matter if it's a windows service or not.

Your windows service can host an application that in turn queries multiple databases. It's just a host that can be started, stopped, paused, resumed and it offers some basic recovery out of the box.

Answer 3

It is hard to say what you'd need to do internally within your service to make this work but what you are building here is effectively a multi-tenant operation inside your service. You are adding an account name parameter that needs to somehow map to an instruction as to which database to use. It actually is pretty straightforward if you've got good dependency injection in place and you have a fixed number of tenants.

This won't quite eliminate the need for a full development version -- unless you want to get into some very fancy footwork with keeping multiple versions of databases and objects straight somehow.

As for the value it depends on what you are doing with it. I've used this sort of setup very successfully in some scenarios where we had consumers that would want to consume and test against different versions of data within the same structure. But building it out had a bit of overhead so I wouldn't do it for the wrong reasons. All in all a better way forward might be to take the pain out of deployment rather than build your app up to multi-tenancy. Especially if there are code differences between dev/qa and production.