Questions about Task Manager
Posted by birdchest on 2008-09-25 03:26
These are just some questions that came up when looking at your code.
1.) Why does the TaskManager class have to be a singleton?
2.) Why did you make the TaskList class?
3.)Do you really want to couple caching with the TaskList?
4.) Why is there an abstract class Task and ITask? (You could probably just have an interface)
5.) The TaskManager is tightly coupled to the HTTP Cache, is that the best choice?
Let me know if you want to discuss some things.
1.) Why does the TaskManager class have to be a singleton?
2.) Why did you make the TaskList class?
3.)Do you really want to couple caching with the TaskList?
4.) Why is there an abstract class Task and ITask? (You could probably just have an interface)
5.) The TaskManager is tightly coupled to the HTTP Cache, is that the best choice?
Let me know if you want to discuss some things.
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Marisic.net is powered by Assembla.
1 Comments
By marisic.net on 2008-09-25 05:13
2. To allow List<Task> to write to the cache
3. Absolutely it's what makes the task become atomized and self running since it hooks into the cache expiration firing a callback method whenever it expires the item from the cache which is what creates this to be able to run an atomic service inside asp.net instead of windows service.
4. i think i just messed up declaring my interface it wasn't letting me add the properties to it, as you mention that I probably just had the syntax wrong and it just needs refactored
5. yes see #3
Basically it's taking advantage of the cache class to create a multithreaded service (i assume multithreaded that IIS will fork a new thread anytime it fires off the cache call back method).
Where i was thinking of taking this with potential future development instead of regulating each task to it's Run() method is to move the tasks execution bodies to asynchronous WCF services and have the Run() methods just initiate a bunch of service client calls to the service and handle running a batch of something with a divide and conquer pattern where the services take a List<ID> or List<Job>.
So Run() wakes up calls like GetPendingJobIds then use an algorithm similar to merge sort to split the id's down to a predetermined length say 64 or w/e and then fire off the asynch service calls to the WCF service and have WCF handle all the multithreading of the smaller batches that were sent to the service.
Did you read my post about this actually creating a task scheduler for running time elapsed batch jobs?
The only thing it needs more of is a better routine to truly scheduling tasks since it's prototyped to just wake up every 1 minute and run the tasks but that's a rather trivial change.