Caching a LINQ to SQL DataContext

views:

answers:

+1 Q:

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?

+2 A:

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.

Marc Gravell 2010-07-30 05:41:22

We've measured. It's not the creation of the dc that's the issue, it's the data attached. Our initial thought was along your lines and we would definitely just re-attach if it were a greenfield development scenario. Before we refactor to rehydrate the context, we want to understand what actually could go wrong if we just leave the dc intact over a short timespan.

Rob 2010-07-30 05:45:22

@Rob - you shouldn't *need* data in your data-context. It is not *meant* to be used as a data store (even *with* the identity-manager). Personally, I would move that data *out* of the data-context; use the data-context to **get** it, but cache it externally.

Marc Gravell 2010-07-30 05:55:28

@Mark - agreed. In a greenfield scenario, that's how we would approach it. The existing repositories are written so that they assume the entities are in the change set, so we would have to rehydrate the context from the cache. Certainly not impossible, and it's likely that's what we'll do, but we want to understand all the issues before we spend limited dev time there.

Rob 2010-07-30 06:02:30

ansaurus

tags:

views:

answers:

Caching a LINQ to SQL DataContext

related questions