Question

I have a project with a number of different classes querying and modifying data in a common set of tables. I’ve set up a .dbml file which provides us with a DataContext class. My question is whether a single instance of the DataContext should be used by all objects, or whether multiple instances are safe to use. I’m also wondering about thread safety in the case of a single DataContext, and whether access to it’s methods should be synchronized.

Answer 1

Rick Strahl has a nice article about your options: http://www.west-wind.com/weblog/posts/246222.aspx.

See also: LINQ to SQL – where does your DataContext live?.

You may want a slightly different strategy for each type of deployment – web, desktop, windows service…

Summarized, your options are:

• Global DataContext – dangerous in multi-threaded environments (including web apps). Remember that instance members are not guaranteed to be thread-safe (from Bradley Grainger’s answer above).
• DataContext per thread – complicated. If your DataContext is tracking changes you must be sure to flush them at the appropriate time. Instantiating, storing, and retrieving the DataContext is a pain.
• DataContext per atomic action – you lose the ability to track changes since one DataContext creates an object while another updates or deletes it. Attaching a data object to a new DataContext may not work like you expect.
• DataContext per data object – seems inelegant because you have to fuss with the DataContext on instantiation(create and attach) and update/delete (pull it off the data object and use it).

I opted for a DataContext per data object. It may not be the fanciest solution but it works in all deployment environments.