July 10, 2008 at 10:58 am
I need to set up a .net multithreaded app that will be kicking off the same update procedure over and over. I know I need to manage the number of threads that can safely be running simultaneously. However, that would appear to mostly limited by the SQL Server 2000 database's processor, memory, and current traffic loading at any particular time. Is there a way determine an optimal number of threads that can run concurrently?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
July 10, 2008 at 11:27 am
I suppose I erred in using the term "recursive procedure call" as that appears to imply a procedure calling itself or others within a nested call stack. I just want to determine a safe figure for how many times a procedure can be called from an external application concurrently without incurring massive record-locking or server crash.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply