Multithreading questions

Hi! My first post here and hoping someone has some answers.

I'm developing an application that will be multithreaded. The primary job of the thread will be to read some xml data from a website, parse it, and save it to sql server. I have a list of customers, each of which I have to get xml data for.

I have a customer class and a list <of Customer> and a dbOps class to handle db operations.

My question is if in the thread's main method, I pass in the customer from the list, instantiate a new dbOps object, does this make calls to the dbOps methods thread safe?

Lets say I have 5 threads doing this and each one has it's own dbops object and each is calling a stored proc to insert of update. Where do I need to worry about thread safety? Do I need to use transactions in the stored procs?

Thanks,

Rut

If all you do is inserting records then it should be thread safe.

I would think that the transactions question has more to do with what commands you are running rather than threading. If you are doing a batch of things, you would still want them to be in a transaction, regardless of whether one or more threads were doing similar things, just because something could fail, and you'd want to roll back the whole thing.

As for the threading, what you are describing is not inherently thread safe, but the way you say you are using it will make it effectively thread safe. The objects are not tied to a thread, but if each thread works with one and only one of the objects, then, by your design, no two threads will ever be running the same code segment. This will not be true if you have shared methods in those objects, since shared methods are not specific to any one object, but otherwise each one will be isolated. You could have trouble if thread A creates a dbOps and ANY other thread is able to call methods against that instance, but you stated that you were not doing that, so you should be fine.

Default question to ask when you're introducing threading:

Does this require threading?

Multi-threading should not be taken on lightly, as it can introduce all sorts of subtle bugs that are very hard to reproduce and debug. The cost of introducing it, therefore, is very high. Make sure the actual benefits (rather than merely perceived benefits that you could also get by a different less costly technique) are worth that cost.

Quote:

---

Originally Posted by Shaggy Hiker

As for the threading, what you are describing is not inherently thread safe, but the way you say you are using it will make it effectively thread safe. The objects are not tied to a thread, but if each thread works with one and only one of the objects, then, by your design, no two threads will ever be running the same code segment. This will not be true if you have shared methods in those objects, since shared methods are not specific to any one object, but otherwise each one will be isolated. You could have trouble if thread A creates a dbOps and ANY other thread is able to call methods against that instance, but you stated that you were not doing that, so you should be fine.

---

Maybe I should ask the question is it better to have one dbops class that all the threads call common code (using synclock) or to keep it the way I have it?

That question probably can't be answered definitively without seeing it. Does the class open a connection? Will there be a prohibitive number of them? If the number is small, then you might be fine with multiples. Heck, you might even NEED multiples. After all, from what description you gave us, it sounds like the class just handles the DB work. If you have only one class, and all the objects have to work through that, you may lose any advantage of multithreading just because all the threads get throttled down by that single chokepoint which amounts to the bulk of their work.