<snip> >> But what's wrong with creating a thread? If you use the >> threadpool it's almost a one-liner!
>Although if you use the threadpool you almost certainly won't be >creating a thread - you'll just be using a thread that was already in >the thread pool most of the time. >And that's typically a good thing of course. You positively don't want >to create a thread just to perform a single operation. >However, in this case it's possible that you'd want to make an >exception. The original poster is talking about something that will >take several minutes to execute. It wasn't clear how many such >operations might be proceeding in parallel. If it's a large number, >then the thread pool is probably a less good choice because of the upper >limit imposed on the number of threads (25 per CPU by default). In this >case creating a thread manually *might* be more appropriate. (On the >other hand, if you're doing something to the database that's taking 10 >minutes, you might not want more than 25 such operations running >concurrently!) In this case, if multiple, long running commands need to execute, its possible that serialization of the commands would be far better than to execute even 2 at once. If a sproc takes 10 minutes, then I would assume it is both IO & CPU intensive, as it is probably executing complicated computations over a large set of code. Executing another proc along side it may well slow both down and result a delay(perhaps 22 minutes for both to finish, while it would have been 20 minutes if executed one after the other). In that case, writing a class that handles the required error handling(perhaps with an event or async model to inform the caller that the call succeeded or failed) and that will serialize all requests into one or two executing threads would be my solution. That would be the simple solution, if a large number of these kind of queries were needed across multiple servers, a manager class with associated async handler classes would probably be a better architecture. The manager, ideally, would accept requests for any server and it would route the request to the proper async handler for serialization and execution. It would also have to manage the number of active threads and would require the handler and the manager to be quite closely related(atleast at the base class level). That solution is probably too complex(and possibly too badly designed) to be of any real use. <snip> =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
