I am working on a asp.net mvc application. I have a situation where I have to make many threads which are going to access the database using linqtosql. My question is, will it be fine to leave every thing on linqtosql to maintain the synchronization, because the threads will be accessing the database at the same time. Or I have to write my own code to do that.
views:
57answers:
3
+4
A:
If each thread is using its own database context, you will be fine. However, I don't believe the database context object is thread safe. So, it's best to make sure each thread has its own context.
Randy
Randy Minder
2009-12-24 21:24:51
A:
If you are using ASP.NET MVC I would seriously take a look at using S#arp Architecture. It uses nHibernate but provides some scaffolding to make the data layer very easy to create and work with. It uses fluent nhibernate and the AutoPersistenceModel so there is no need to play with XML files for mappings. It also includes a number of very handy to have MVC tools.
Linq2SQL seems to have some pretty serious shortcomings whenever I've tried to do anything remotely sophisticated with it and I would probably only recommend it for very simple scenarios. Perhaps it's just me but I have observed some pretty ugly behaviour with L2S.
Chris Nicola
2009-12-24 22:32:03
LINQ to SQL is intended to be a simple tool, so it will not map well to sophisticated usages. That's not a shortcoming, it's just differently-purposed. The tradeoff is the practically nonexistent learning curve and extremely fast setup - usually less than 5 minutes to get a full map up and running.
Rex M
2009-12-24 22:45:45
If the author needed advice on a framework on top of ASP.Net MVC this could have been a useful answer. But whether or not L2S has its shortcomings (it probably has) is irrelevant for this question.
jeroenh
2009-12-24 22:46:55
Yes, perhaps "shortcomings" was the wrong word, however I felt I was clear that I was referring to my own experience, so YMMV.As soon as you get into threading issues, it is safe to assume the situation is moderately sophisticated. Enough that you may want to reconsider L2S.The author asked if (paraphrased) "it would be fine to leave everything to linq2sql". So I would think any "shortcomings" would be relevant. Suggesting an alternative approach also seemed like a helpful idea. It may not be the answer the author is looking for, but I'm not sure it required a downvote...
Chris Nicola
2009-12-24 23:52:04
Whenever you using linq-to-sql in a website, you're also using it in a multi-threaded environment. There shouldn't be any problem with multi-threading as long as each thread has its own DataContext. You need that anyway, because the context has to be short-lived (one per unit of work), or you'll get other problems, regardless of threading.
Sander Rijken
2009-12-26 08:58:15
+1
A:
I'm not sure what kind of synchronization you mean, but databases have been designed such that multiple clients (threads, processes, machines) can access/read/change data at the same time. Linq2Sql is - speaking very simply - just one of the mechanisms to emit SELECT/DELETE/UPDATE statements against the database.
liggett78
2009-12-24 22:41:12