ThreadPool Tasks That Depends on the Completion of Other Tasks

Question

In our current project, for some operations we send messages to Database like COMPLETED-Order,STARTED-Request, REJECTED-Order with related information like OrderId.... All the messages correspond a Command class that implements Command Pattern.

interface ICommand
{
   void Execute();
}

public class RequestStartedCommand:ICommand
{
   public void Execute()
   {
     //do the related work.....
   }
}

//other commands...

A windows service consumes this messages then converts them above commands and executes commands by a ThreadPool.

But some commands needed to be executed before other commands like OrderID=23's COMPLETED-Order command must be executed before same order's REJECTED-Order command. How can I do this or Which strategy should I follow? Any examples or documentation would be usefull.

Answer 1

I would try to implement some dependency check. Something like that rejected order command needs to check for some state to be valid before it can be executed. The manager/service shoudl take the command from the list, apply its validation check and return it to the list if such a validation is not complete.

Beware of starvation, or for a command to get stuck in the list forever.

Answer 2

We've been using Smart Thread Pool written by Ami Bar to accomplish this. It's been in production for a few years now and was chosen because we found the implementation in .NET 1.1 lacking at the time.

STP implements workitem groups which can be used to queue related work items if you set the group's number of concurrent threads to 1. With 50-100 online clients we haven't experienced any problems using it.

Answer 3

I would create a method to chain commands together and use events to notify other commands of completion, success, failure, or cancelled commands. Check out the observer pattern (http://en.wikipedia.org/wiki/Observer%5Fpattern) for an idea of how you can pass these notifications around. Also, beware of circular dependencies in your commands so if two commands are waiting on each other, then neither one will ever execute. I would probably use events for implementing this.