(Revisit) Session Specific Cache

My question

Is using st.session_state as a session specific cache correct and intended usage of the session state?
Does it release its values when the session closes and are they collected by GC?

Background and details

I wanted a session specific cache mechanism to set, for example, stateful deep learning models,
and I found this thread: Session Specific Caching where using st.cache with session_id has been recommended.

However, I think st.cache with session_id can’t release the cached objects when the session ends so it may lead to memory leaks.
Actually, I encountered frequent crash errors when I used this technique in my app deployed on Streamlit Cloud (that version is not active now, but the code is streamlit-webrtc-example/app.py at ae6b0ae54112135c3e4c6be75e9267383085c444 · whitphx/streamlit-webrtc-example · GitHub),
although I have not measured the metrics.

Then I switched to using st.session_state for that purpose as this new feature has been introduced since the prev thread was closed and it seems to suit my use case. Actually, after this version has been deployed, the error frequency has decreased.
(The code is streamlit-webrtc-example/app.py at bc98518324d14a4f86337252675578a042e3005b · whitphx/streamlit-webrtc-example · GitHub)

Is my idea correct? Are there any concerns?

1 Like

I relayed this to Tim from Eng, who says:

each session’s SessionState instance is tied to the app session instance, so it should be released (eventually! because GC is non-deterministic) when the session ends. If not, it’s a buggy-bug.

1 Like