I'm writing http session manager (gen_server based). That server creates and removes session from in-memory storage. I need to remove expired session on timeout. I have two solutions:
First solution locks server while all sessions are not processed (lock issue). Second solution takes process for each session (memory issue).
Question is which solution is right?
Thank you!
A low frequency event should be handle by a low frequency process IMO. You don't want to be "spending" too much resources on something that's not "generating" value.
The "clean-up" activity does not appear to require "locking-up" the server. Maybe you need to expand on this point.
Why do you need to "lock" something in your solution #1? What are your concerns here? Please detail your concerns a bit more so I can provide more suggestions.
This is how I handle sessions in my pet "web framework".
Worker processes directly look up existing sessions and create new sessions into an ets table (without any server intervention). Also worker processes check after successful lookup if the session is dead. If so, it creates a new session, and deletes the old one. As the ets table need not be ordered, write concurrency can be enabled.
The role of the "session server" is to own the session table, and to spawn a cleanup process every now and then. This is a low prio process that goes through the ets table with ets:next() calls, and deletes expired sessions.
Note that there are no timers involved.
Use timer:send_after, timer:exit_after or timer:kill_after. timer module uses ets for store timers and there is only one gen_server for whole VM. Store timer reference in each session record for timer restarting or so. It is simple and clean solution.
You cant really go wrong with any of the suggested solutions as long as you dont have ginourmous numbers of sessions. And what im saying with that is that you should benchmark.
The timer module is implemented as an ordered ets table where ets:first can efficiently find the first timer that should expire and sleep until that happens. So there is no problem in adding many thousand timers through the timer module. One per session.
If you have very many sessions, then the problem of having a fail safe design is likely a larger issue. You would need to distribute your session database so requests can be load balanced and you're not vulnerable to any one web server machine going down.
And that is how specific I feel one can be without the functional requirements.