LINQ to SQL in multi-threaded environments

[Eric Falsken]

*background*
I've got an application that I'm creating that is using LINQ to SQL. We have
a nice DataContext that is able to do lots of nice updating. But we are using
something like an MVC model where the controllers are doing the updating.
Since objects have to be updated/deleted to the same CataContainer that they
were retreived from. So to solve "attach" and "detach" issues, we just make
sure that the "Controller" in our setup is static. (using the Provider model)

*question*
But now that the Context is shared among all our requests, calling
DataContext.Submit() will submit ALL changes to ALL objects that came from
the DataContext, even if the changes are incomplete or in the process of
being made still. Heck, some changes might not even get past validation. How
can I call Submit() to apply some changes but not others? Is there some way
to do this with transaction sopes? e.g.

MyObject obja = context.Table.First();
MyObject objb = context.Table.Second();
objb.Name = "name2"; //could be happening in another thread
using (TransactionSope ts = new TransactionScope()){
obja.Name = "name1";
context.Submit(); //objb should not be updated here
}

 

[Steven Cheng [MSFT]]

Hi Eric,

For your scenario, I think the problem is how to make each "submit"
operation to associate with its own DataContext data. If you're using a
shared single Datacontext instance, I'm afraid that will be very
inconvenient and inefficient. That means in multi-threading environment(if
multiple thread can access it), you will need to perform locking in order
to serialize all the data operations. For example, you can define a helper
class which expose a static method that will accept the parameters and call
the single DataContext to do the submit operation. In that function, the
code is somewhat like:

lock ( a private object reference)
{
//code here to do submit via the shared DataContext
}

Such code will be overkill if there are many concurrent thread requesting
for such submit operation.

BTW, I don't think TransactionScope will help much here since
TransactionScope is mainly used for group multip operations to be finished
as atomic task suite instead of ensuring thread-safety or method reenter.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------