linq to sql in a multithreaded environment ( and WCF)

Question

Hi All,

we have designed a multi threaded server that use linq to sql at each of its threads. the test are not look so good... from reviewing our code, a big question has be raised: does linq to sql supports such environments at all? if yes, we assume that we should create a dedicated DataContext object for each thread? if yes, what is the cost of such approach?

if it will be to complicated, I guess we will dump the linq to sql and roll back to connected approach.. (?)

similar question was raised from the (Per Call)WCF based API side: we use a singleton DataContext object for all WCF function calls? or should we initiate a DataContext for each WCF API call?

Thanks! ofer

Answer 1

This article provides some great solutions:

http://www.west-wind.com/weblog/posts/246222.aspx

Answer 2

Threads have their own respective stack of variables and references. So yes, I believe you would need a DataContext for each thread.

Answer 3

DataContext

Any instance members are not guaranteed to be thread safe.

Read as: this class is not thread safe and instances should not be shared between threads unless you implement locking.

Be aware that (by default) datacontexts track the record instances that they load - those instances should also not be shared between threads. Those tracked record instances are not refreshed for changes in the database automatically when requeried.

Be aware that calling SubmitChanges on a datacontext sends all modified records that it is tracking back to the database... this could be really bad with multiple users sharing a datacontext even with locking.

---

Also from the same article:

In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.

---

if it will be to complicated, I guess we will dump the linq to sql and roll back to connected approach..

You should also not share a SqlConnection object between threads without implementing locking.