Redis backed ASP.NET SessionState provider [closed]

Question

I'm currently developing an ASP.NET SessionState custom provider that is backed by Redis using Booksleeve. Redis seemed like a perfect fit for SessionState (if you must use it) because:

• Redis can store durably like an RDBMS, however it is much faster.
• A Key/Value datastore better fits the interface of SessionState.
• Since data is not stored in-process (like the default Session provider), SessionState can live out web server restarts, crashes, etc.
• Redis is easy to shard horizontally if that becomes a need.

So, I'm wondering if this will be useful to anyone since we (my company) are considering open sourcing it on GitHub. Thoughts?

UPDATE:

---

I did release a first version of this yesterday: https://github.com/angieslist/AL-Redis/blob/master/AngiesList.Redis/RedisSessionStateStore.cs

Answer 1

I've created a Redis-based SessionStateStoreProvider that can be found on GitHub using ServiceStatck.Redis as the client (rather than Booksleeve).

It can be installed via NuGet with Install-Package Harbour.RedisSessionStateStore.

I found a few quirks with @NathanD's approach. In my implementation, locks are stored with the session value rather than in a separate key (less round trips to Redis). Additionally, because it uses ServiceStack.Redis, it can used pooled connections.

Finally, it's tested. This was my biggest turn off from @NathanD's approach. There was no way of actually knowing if it worked without running through every use case manually.

Answer 2

Not only would it be useful, but I strongly consider you look closely at the Redis' Hash datatype if you plan to go down this road. In our application the session is basically a small collection of keys and values (i.e.: {user_id: 7, default_timezone: 'America/Chicago', ...}) with the entire user session stored under in a single Redis hash.

Not only does using Hash simplify mapping the data if your session data is similar, but Redis uses space much more efficiently with this approach.

Our app is in ruby, but you might still find some use from what we wrote.