Design related question

microsoft.public.dotnet.framework

11 Jul 2006 9:36 AM

Water Cooler v2

I want my application to do three tasks simultaneously. Each of the
three tasks must be performed at a periodic interval of time. Each of
the three tasks is somewhat complicated and is thus composed of a
number of sub-tasks that are to be performed in a linear sequence.

The three tasks are independent of each other. They do not share any
data, nor is the execution of one going to affect the other.

To ampify, assume I have three main tasks as:

Task A [performed simultaneously with Task B and Task C]
    - Sub-task A.1 (sub-task within Task A)
    - Sub-task A.2 (performed in linear sequence after A.1)
    - Sub-task A.3 (performed after A.2)

Task B
    - Sub-task B.1 (sub-task within Task B)
    - Sub-task B.2 (performed in linear sequence after B.1)
    - Sub-task B.3 (performed after B.2)

Task C
    - Sub-task C.1 (sub-task within Task C)
    - Sub-task C.2 (performed in linear sequence after C.1)
    - Sub-task C.3 (performed after C.2)

The question is: how should I design my application. I am thinking of
the following options:

1. One glob executable that runs as a service and manages Task A, Task
B and Task C as three separate threads. Each thread fires off a timer
so that the thread is always active and it executes periodically.

This will, however, involve a buttload of thread management. Also, if
one thread misbehaves, the whole application will come to a halt. It
would be wrong to couple them in one process given that the tasks are
independent of each other.

2. Make each task into a separate EXE. In each EXE, take a timer that
executes the sub-tasks in linear sequence.

Create a Windows Service that watches over these independent process.
If one of them crashes or misbehaves, the Windows Service writes to the
Event Log, cleans up memory and re-starts the process afresh.

If you were in my position, what would your take on the design be? What
would you recommend?

11 Jul 2006 9:44 AM

Hello,

I was thinking of a third approach:

I think you should have the 1st approach with a difference:
1. The thread management is not that bad really (i have a general
purpose task schedular which deals with many threads, and the total
threading code is only 5-10 lines), since your problem is limited to 3
threads. You could use the ThreadPool or make your own threads.
2. As for the thread managment, here you can borrow from your second
approach: in that you model each of your tasks as a function in some
class, and then make sure that the function handles all exceptions that
the task can throw, and then use reflection to load this class and call
that function. This way, you have three different Dlls, each one
implementing one task, and each has a function which executes the
actual task.
3. You can then implement independent timers for each task and maybe a
4th management timer for checking the status of each task timer, etc.

its not that complicated, give it a try, let me know if you need any
help.

- Vaibhav

Water Cooler v2 wrote:
Show quote

> I want my application to do three tasks simultaneously. Each of the
> three tasks must be performed at a periodic interval of time. Each of
> the three tasks is somewhat complicated and is thus composed of a
> number of sub-tasks that are to be performed in a linear sequence.
>
> The three tasks are independent of each other. They do not share any
> data, nor is the execution of one going to affect the other.
>
>
> To ampify, assume I have three main tasks as:
>
> Task A [performed simultaneously with Task B and Task C]
>     - Sub-task A.1 (sub-task within Task A)
>     - Sub-task A.2 (performed in linear sequence after A.1)
>     - Sub-task A.3 (performed after A.2)
>
>
> Task B
>     - Sub-task B.1 (sub-task within Task B)
>     - Sub-task B.2 (performed in linear sequence after B.1)
>     - Sub-task B.3 (performed after B.2)
>
>
> Task C
>     - Sub-task C.1 (sub-task within Task C)
>     - Sub-task C.2 (performed in linear sequence after C.1)
>     - Sub-task C.3 (performed after C.2)
>
>
>
> The question is: how should I design my application. I am thinking of
> the following options:
>
> 1. One glob executable that runs as a service and manages Task A, Task
> B and Task C as three separate threads. Each thread fires off a timer
> so that the thread is always active and it executes periodically.
>
> This will, however, involve a buttload of thread management. Also, if
> one thread misbehaves, the whole application will come to a halt. It
> would be wrong to couple them in one process given that the tasks are
> independent of each other.
>
>
> 2. Make each task into a separate EXE. In each EXE, take a timer that
> executes the sub-tasks in linear sequence.
>
> Create a Windows Service that watches over these independent process.
> If one of them crashes or misbehaves, the Windows Service writes to the
> Event Log, cleans up memory and re-starts the process afresh.
>
>
> If you were in my position, what would your take on the design be? What
> would you recommend?

11 Jul 2006 9:58 AM

pranshu

Hello
If the time interval is user customizable and if the time of the day is
important, you might want to create the programs as EXEs and trigger
them by windows scheduler. It is a lot easier for end users to
customize the scheduled intervals that way.

You have to keep a lot in mind if you are creating a service with
timers - like time of first run, manual re-run etc. For example, if the
jobs need to run once in three days - would you make them run
immediately on start of service for the first time, or after three
days? Considerations about what if the job runs too soon or too late
have to be considered - or you need to store last run times etc. in the
database.

Clustered application add another level of complexity.
If there are three application servers in your cluster - would you run
it on one or all three? How will you manage high availability if its
only one and how would you manage concurrency control if its all three.

Pranshu