views:

68

answers:

3

I'm building a console application which imports data into databases. This is to run every hour depending on an input CSV file being present. The application also needs to be reused for other database imports on the same server, e.g. there could be up to 20 instances of the same .exe file with each instance having their own separate configuration.

At the moment I have the base application which passes a location of config file via args, so it can be tweaked depending on which application needs to use it. It also undertakes the import via a transaction, which all works fine.

I'm concerned that having 20 instances of the same .exe file running on the same box, every hour, may cause the CPU to max out?

What can I do to resolve this? Would threading help?

+1  A: 

Each executable will be running in it's own process, and therefore, with it's own thread(s). Depending on how processor intensive each task is, the CPU may well max out but this is not necessarily something to be concerned about. If you are concerned about concurrent load then the best way may be to stagger the scheduling of your processes so that you have the minimum number of them running simultaneously.

AdamRalph
That doesn't exactly answer the question. This won't guarantee that just one single instance is running.
OJ
I don't see that requirement mentioned anywhere - the question seems to be asked for the assumed standpoint that there will be multiple instances of the exe running - or am I missing something?
AdamRalph
Sorry, I should have made this a little clearer. I do want multiple instances I just don't want the server to grind to a halt because I have too many processes running.
StuffandBlah
I agree with @AdamRaplh. Do some testing to find out how much CPU and memory each instance will take. Then stagger the start time or upgrade your server, or optimize your code, or all three.
iamdudley
StuffandBlah
A: 

No, this isn't a threading issue.

Just create a system-wide named Mutex at the start of the application. When creating that Mutex, see if it already exists. If it does, it means that there is another instance of your application running. At this point you can give the user a message (via the console or message box) to say that another instance is already running, then you can terminate the application.

OJ
This would force only one such process, but if processors are not the bottleneck here then this would reduce performance.
Dialecticus
A: 

Why not make a single instance that can handle multiple configurations? Seems a lot easier to maintain and control.

Doggett
The issue with a single instance is that the process may run for several minutes. If there are 20 different DBs that need importing then effectively you would need to queue each DB transaction (that is one way of doing it anyway). Another option is for me to convert the console app into a windows service and make it so it scans for CSV files rather than scheduled runs. At the point of a CSV being available it could kick off the import process, which could be threaded.
StuffandBlah