ASP.NET 5 (Core): How to store objects in session-cache (ISession)?

Question

I am writing an ASP.NET 5 MVC 6 (Core) application. Now I came to a point where I need to store (set and get) an object in the session-cache (ISession).

As you may know, the Set-method of ISession takes a byte-array and the Get-method returns one.

In a non-core-application I would use the BinaryFormatter to convert my object. But how can I do it in a core-application?

Solution 1

I'd go with serializing the objects to JSON and use the extensions methods on ISession to save them as string's.

// Save
var key = "my-key";
var str = JsonConvert.SerializeObject(obj);
context.Session.SetString(key, str);

// Retrieve
var str = context.Session.GetString(key);
var obj = JsonConvert.DeserializeObject<MyType>(str);

The extension methods on ISession are defined in the Microsoft.AspNet(Core).Http namespace.

Solution 2

This is an evergreen post and the problem is still fresh, and even though Microsoft has recommended serialisation to store the object in session - it is not a correct solution unless your object is readonly, I have a blog explaining all scenario here and i have even pointed out the issues in GitHub of Asp.Net Core in issue id 18159

Synopsis of the problems are here:

A. Serialisation isn't same as object, true it will help in distributed server scenario but it comes with a caveat that Microsoft have failed to highlight - that it will work without any unpredictable failures only when the object is meant to be read and not to be written back.

B. If you were looking for a read-write object in the session, everytime you change the object that is read from the session after deserialisation - it needs to be written back to the session again by calling serialisation - and this alone can lead to multiple complexities as you will need to either keep track of the changes - or keep writing back to session after each change in any property. In one request to the server, you will have scenarios where the object is written back multiple times till the response is sent back.

C. For a read-write object in the session, even on a single server it will fail, as the actions of the user can trigger multiple rapid requests to the server and not more than often system will find itself in a situation where the object is being serialised or deserialised by one thread and being edited and then written back by another, the result is you will end up with overwriting the object state by threads - and even locks won't help you much since the object is not a real object but a temporary object created by deserialisation.

D. There are issues with serialising complex objects - it is not just a performance hit, it may even fail in certain scenario - especially if you have deeply nested objects that sometimes refer back to itself.

The synopsis of the solution is here, full implementation along with code is in the blog link:

1. First implement this as a Cache object, create one item in IMemoryCache for each unique session.

2. Keep the cache in sliding expiration mode, so that each time it is read it revives the expiry time - thereby keeping the objects in cache as long as the session is active.

3. Second point alone is not enough, you will need to implement heartbeat technique - triggering the call to session every T minus 1 min or so from the javascript. (This we anyways used to do even to keep the session alive till the user is working on the browser, so it won't be any different

Additional Recommendations

A. Make an object called SessionManager - so that all your code related to session read / write sits in one place.

B. Do not keep very high value for session time out - If you are implementing heartbeat technique, even 3 mins of session time out will be enough.