Multiple/single instance of Linq to SQL DataContext

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.

Leave a Comment