Transactions in a Windows Service

[Guest]

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

 

[Willy Denoyette [MVP]]

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?

Users should not be able to stop services, only administrators should have this privilege.

Should I wrap the other program within a transaction?

This is not what transactions are meant for, the "other" application should care about this
by means of transactions and restart points, but this highly depends on what kind of
application it is.

Willy.

 

[Guest]

Hi Willy

Thanks for the prompt reply. The "other" application sychronizes SQL Server
tables with SQL statement etc. so presumably would be an ideal candidate for
transactions.

Would it be worth passing the service state to the "other" program if it was
stopping?

 

[Willy Denoyette [MVP]]

Hi Willy

Thanks for the prompt reply. The "other" application sychronizes SQL Server
tables with SQL statement etc. so presumably would be an ideal candidate for
transactions.

Sure, but you still need restart points if you need to recover from application or system
crashes.

Would it be worth passing the service state to the "other" program if it was
stopping?

What problem would it solve? Why is it important for the spawned process to know the state
of it's parent?
Windows services are meant to run from boot to shutdown time, so, they should be designed to
be as robust as possible. Critical services should be designed such that are restart-able,
that is, they should use restart points, so that they can pick-up and continue after a crash
or planned stop. However, your service should not try to recover the spawned processes
activities, that's the task of the spawned process.


Willy.

 

[Guest]

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)