CODEWITHSUNDEEP
c#linq-to-sql
Rob
Rob

Reputation: 5603

Caching a LINQ to SQL DataContext

We're in the process of doing some performance optimization for a multi-tenant Web application. Currently, a LinqToSql Data Context is created at the beginning of each web request. The context has a lifetime for the web request and it's injected into the constructor of any objects that need it using Castle Windsor.

We had the thought of caching the context (and a set of objects attached to it) in the session cache for up to a few minutes to optimize the setup costs for follow-on web requests. Is this a good/bad idea? What issues need to be considered?

Upvotes: 1

Views: 622

Answers (1)

Marc Gravell
Marc Gravell

Reputation: 1062660

A bad idea IMO. The biggest problem would be concurrency. Thanks to connection-pooling, the costs aren't that much as long as you use the data-context as a pipe for data, not the data bucket itself.

Cache the data; throw away the data-context.

Attempting to hold onto the data-context additionally doesn't scale out to multiple servers, or support any cache implementation except in-process.

Have you measured the setup costs so that you know whether this is worth considering? I really don't believe that is your bottleneck.

Upvotes: 2

Related Questions