SessionManager infinitely caching sessions in loaded_sessions about tower-sessions

[maxcountryman]

It's something I'm actively working on improving: ideally it would only hold onto loaded session memory for as long as it's needed. This is complicated by concurrency. One idea is to track the count of references a la Arc, removing the session from the loaded cache when it's safe to do so based on reference count.

This is a long way of saying that while currently additional caching seems superfluous, that likely will not be true in the future.

[renbou]

Why should it be implemented in SessionManager by default, though? Smart reference-counting caching can be done elsewhere, it doesn't sound like a feature that should just be enabled for all consumers of this library. Since it is enabled by default, it pretty much means that this library is unusable in its current state.

[maxcountryman]

Since it is enabled by default, it pretty much means that this library is unusable in its current state.

Can you expand on why you think that's the case?

I would argue the vast majority of applications will have a small number of loaded sessions and relative to other things this is not a great deal of memory, even as it grows.

I did some load testing and indeed, memory growth is quite small.

That said, addressing this shouldn't be too difficult and will land in a patch release soon assuming one of the potential implementations works.

As for why it's required: concurrent data access requires the manager to expose shared memory unless you want to serialize session access altogether.

[renbou]

As soon as a web app exposes an endpoint which creates new sessions, requests can simply be issued to said endpoint in order to infinitely fill the SessionManager's cache, which is a problem even if the memory growth rate is indeed small

[maxcountryman]

Please feel free to open a PR.

We want to preserve concurrent data access, which requires ensuring that loading and saving is done such that a load will not introduce stale data to handlers.

A naive but incorrect solution is to lock the request through the response and store save but this blocks concurrent access. For this reason, we manage the session memory via DashMap (altho in the future scc or some other interface entirely might be preferable).

As I mentioned earlier, you could track references within the map itself and when that count is such that there is no concurrent access, you can remove the session.