I have worked on a similar problem before where I designed a Windows service
that hosted several virtual services. The following solution assumes that you
have access to the code of the other application.
1. Set a timer on the windows service.
2. Start the other process on a new thread (if it is already not running) on
the tick event.
3. When the service is stopped, call the Stop method on the other process.
Let the process shut itself down gracefully and notify the parent through a
callback. I prefer to use a "soft" shutdown, which means that I use a
configuration file to control this behaviour. There is a very small time
limit of shutdown behaviour when used thru the Service control manager.
4. The parent can wait a specified amount of time for the other process to
fininsh (again configurable via config file) and then shut itself down
gracefully. If the other process does not reply in the specified time, then
the parent can force a shutdown with a potential loss of data (kill the
thread). If you design the other process carefully, then this last resort can
be minimized.
And yes to avoid nasty surprises from events beyond your control, the other
process should be designed with a rollback mechanism (like transactions).
However the Windows service host should not care about that and all it should
be concerned with, is to notify the child process when it is shutting down.
Hope I have helped.
--
Good luck!
Shailen Sukul
Architect
(BSc MCTS, MCSD.Net MCSD MCAD)
Ashlen Consulting Service P/L
(
http://www.ashlen.net.au)
"jez123456" wrote:
Hi Experts
I've written a c# windows service which runs another program at certain
intervals. The other program may take upto 20 minutes to complete it's tasks.
My question is what happens to the other program if a user decides to
manually stop the service (or there was a power cut) when the tasks have not
fully completed?
Should I wrap the other program within a transaction?
Is this the best approach or am I making things over complicated?
Many thanks