0

I will host my ASP.NET MVC4 app as a redundant Azure app. During a session, the app performs computationally expensive operations that produce non-serializable objects. Creation of the objects is repeatable; I could perform the expensive operation each time I need the object, but I would prefer to just do it the first time and save the object for later reuse.

I want to use the standard distributed session state mechanism in Azure for storing the usual session state info, but that mechanism requires that session data be serializable. Is there another mechanism I can use to cache the expensive-to-create, non-serializable objects?

Bob

Bob.at.Indigo.Health
  • 11,023
  • 13
  • 64
  • 111

2 Answers2

2

All distributed cache services provided by Windows Azure need serialization currently, not only the shared cache, but dedicate/co-located cache as well.

But it's not necessary to serialize if you are going to use in memory cache. But this is not good for scaling-out, and you may not be able to have azure SLA if you've only 1 instance.

So my suggestion is to optimize your serialization and try to use azure cache.

Shaun Xu
  • 4,476
  • 2
  • 27
  • 41
1

Do these objects have to be stored in centralized storage or can you store them in the "InProc" session state?

If not, I'm afraid you'll need to serialize them into something (either SQL Azure, file, app-fabric cache, etc).

So either find a way to serialize them into something persistable or store them in RAM, with an extra copy on every web server

Igorek
  • 15,716
  • 3
  • 54
  • 92
  • Thanks Igorek! No, I don't need centralized storage (which, obviously requires serialization). I'm looking for something that lets me fabricate my objects as needed on each server instance, and just keep a local copy alive for reuse on that server instance. I'm new to this whole web programming thing, so I need help figuring out how to map basic terms like "InProc session state" and "store them in RAM" into the reams of magic that is ASP.NET. – Bob.at.Indigo.Health Nov 26 '12 at 21:32
  • Would these objects be global to every session? If so, you can use public static declarations inside a public static class to declare these (wrap their setting with a lock() statement to prevent multi-threading issues). http://stackoverflow.com/questions/5118610/asp-net-mvc-global-variables – Igorek Nov 27 '12 at 02:46
  • Fascinating. Ok, so let me make sure I understand this: My web app (whether hosted by Azure or by someone's ASP.NET hosting service) runs in the context of one or more server instances. Each server instance loads my assemblies once when it starts up, and keeps them loaded forever (or until it meets an untimely end). Thus, public static data lives as long as the server lives. And, by the way, make sure static data access is thread safe. (Continued in next comment...) – Bob.at.Indigo.Health Nov 27 '12 at 04:15
  • So, it seems that it should be pretty easy for me to create a SessionCache class that encapsulates the process of creating a Dictionary that is added to a public static dictionary using the session ID as a key, using that per-session dictionary to store stuff, and deleting that per-session dictionary when the session goes away. Here's a related question: Am I guaranteed that there is only one thread executing at a time associated with a given session ID (unless I explicitly create multiple threads)? – Bob.at.Indigo.Health Nov 27 '12 at 04:20
  • Yes. You should make the collection thread-safe. However, if you have nothing else that you're storing in Session state besides this or you don't have anything else that you need to keep centralized, I'd recommend using HttpContext construct to store SessionData in there using InProc provider. That construct will keep the cache dictionary pruned to active sessions only – Igorek Nov 27 '12 at 04:34
  • I do have some basic session state data that needs to be centralized. I assume that there is no way to get the best of both worlds and use a distributed (sereialized) session state provider for some data and the InProc (non-serialized) provider for fast cache. Otherwise it looks like I'm stuck using the distributed provider for my normal session state stuff and I'm on the hook to build my own (or find a ready-to-use) local InProc session cache. – Bob.at.Indigo.Health Nov 27 '12 at 22:26