Implement custom session-like cache in Sitecore

Question

Due to limitations outside my control I will have to store custom objects for each logged in user of my Sitecore site. Currently this is getting stored in session state. There is alot of pressure on the session state store at high load due the exclusive locks in the session store as described in this article by Sitecore. Per this article storing custom objects in session should be avoided and should be stored in a custom cache instead.

Has anyone implemented such a custom cache and if so how was this done? I'm looking for the same behavior for this custom cache as session state, e.g. unique to the current user's browser session, terminate when the session is ended, available to all requests in the session only etc.

FYI, my issues are related to the exclusive locks in the session store. The newer Microsoft.AspNet.SessionState.SessionStateModuleAsync allows multiple requests per session through aspnet:AllowConcurrentRequestsPerSession setting. AFAIK this session state module is not supported by Sitecore. If anyone has fixed this issue this way then I would be very interested in the appoach as well.

Answer 1

I have done something similar, although not exactly a custom cache that is the equivalent of a Session State.

In my project we used couchbase although the principles could easily be applied to Redis too.

We wrote a simple ICacheProvider that gave us all the properties/methods we needed and registered it with the container as Scoped, so we get a per request singleton. That performed better with creating and destroying connections etc... YMMV if you use Redis, follow the best practice there.

Then you can just use that cache provider in a similar way to how you would use the Session. Just add the objects into the cache, provide a unique key - in your case you could easily use the Session Id and then provide a way for the cache to expire.

If you are using the Session Id as the unique key, you could simple have a long duration for the cache, maybe 24-48 hours before it expires. Its unlikely that a session would last longer than that, the next time the user logs into the site, they would get a new session Id anyway. Its hacky, but should work.

Alternatively, you could hook into the session_end event and invalidate the cache directly that way.

Once you have it all created, you would simply swap your existing Session State calls, and replace them with your custom Redis/Couchbase cache provider calls.

The big advantage of using a distributed provider for your cache is that you don't need to worry about sticky sessions or requests going to different load balancers, all instances will read from the same cache, similar to how the Redis/SQL Server session state management works.

There are a number of good references for how to use Redis as a cache:

• https://www.c-sharpcorner.com/article/five-best-ways-to-use-redis-with-asp-net-mvc/
• https://jakeydocs.readthedocs.io/en/latest/performance/caching/distributed.html
• https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-web-app-howto