Do we really want Arc<Mutex<HashMap<K, V>>>?

[avdb13]

I was glancing through the codebase and saw that the MemoryStore is really just a Arc<Mutex<HashMap<K, V>>>. As I'm using the MemoryStore in production (logging out all users on restarting the server is not a big deal) I was on the other hand a bit worried about the fact that all user sessions can only be accessed one at a time.

[maxcountryman]

You're absolutely right. It's not intended to be used in production (maybe consider MokaStore instead) and is really only meant for testing.

[avdb13]

Oh, so moka is an in-memory cache like Redis? That will do for my usecases, I just don't think many people heard of it so they'll just assume it's a complete DB engine. The production warning for MemoryStore could include use Moka instead if you want an in-memory store or something. What do you think?

[maxcountryman]

That warning makes sense to me.

I also believe that Moka can be unbounded when its capacity is set to zero, so that would effectively make it a direct replacement for the memory store we have today.

[avdb13]

In that case do you think it would be a good idea to just deprecate the memory store altogether? having Moka enabled as the default isn't gonna require anything more than an extra crate as a dependency right?

[maxcountryman]

I think it should be possible for applications to opt out of Moka. So yes, either way, MemoryStore should probably be deprecated.

[maxcountryman]

Another thought here: we could use dashmap instead. The API diverges from HashMap a bit, but it's close to a drop-in replacement.

Or maybe we should alias MemoryStore to MokaStore (it's not exactly one-to-one because MokaStore is bounded to a fixed number of total LRU entries).

Anyway I'm happy to make changes and I would also like to make sure that folks aren't reaching for this in production settings unless they're sure it's the right tool for their needs.

[maxcountryman]

I think we can mark this as resolved, but please let us know if you have additional questions.