We have an MVC project that is going to handle displaying a trace logging mechanism that collects data from several applications that all relate to one master application suite. The Trace logging tool is a service that collects exceptions and other various logging information and places them in a database for later consumption. This MVC project is part of that consumption.
As I'm sure you can tell, there is a lot of data that is returned via Entity / LINQ. Right now the developer is getting all the data back and is using a session variable to hold this data ( i think he said it's like a good 3-5 MB worth of data that is getting returned.). Only 512 traces are sent back to the view / browser. The user then has the ability to filter by anything they type via AJAX call. The developer is using the old Session["name"] object to put the data in and is using LINQ to filter through it on the server so that he is not hitting the Tracing service everytime a filter is selected / typed.
It works locally, but not remotely. I'm thinking there is an issue on IIS, but haven't looked into that yet.
I was wondering if Sessions are the best approach for large data like this, or if there is a better recommendation instead of Sessions that would be better.. I know MVC is stateless and I try to keep it clean of anything but TempData as best I can, but unsure how to tackle this otherwise
It could be better to use HttpRunTime.Cache to store the data as it has flexibility in how it is expired, especially if the traces are global to the application, e.g.
private List<string> GetApplicationSuiteTraces()
{
List<string> applicationSuiteTraces = Cache["ApplicationSuiteTraces"];
if(applicationSuiteTraces == null)
{
applicationSuiteTraces = Service.GetTraces();
Cache.Add("ApplicationSuiteTraces", applicationSuiteTraces, null, DateTime.Now.AddSeconds(600), Cache.NoSlidingExpiration, CacheItemPriority.High, null);
}
return applicationSuiteTraces;
}