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?
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.