Erlang: session management and timeout

Question

I am writing an http session manager (gen_server based). This server creates and deletes a session from memory to memory. I need to delete an expired session by timeout. I have two solutions:

• Create one timer to delete expired sessions from dispatcher
• Creating a timer for each session

The first solution blocks the server until all sessions are processed (blocking problem). The second decision is made by the process for each session (memory problem).

Question: which solution is correct?

Thanks!

Answer 1

Use timer:send_after , timer:exit_after or timer:kill_after . The timer module uses ets for storage timers, and there is only one gen_server for the entire virtual machine. Keep a timer in every session entry to restart the timer or so. This is a simple and clean solution.

Answer 2

The low-frequency event must be handled by the low-frequency IMO process. You do not want to "spend" too many resources on something that does not "generate" a value.

The activity of "cleaning" does not require "blocking" the server. Perhaps you need to expand this point.

Why would you “block” something in your No. 1 decision? What worries you? Please provide details of your concerns so that I can provide more suggestions.

Answer 3

This is how I handle sessions in my home web environment.

Workflows directly look at existing sessions and create new sessions in the ets table (without server intervention). Workflows are also checked after a successful search if the session is dead. If so, it creates a new session and deletes the old one. Since the ets table does not need to be ordered, you can enable the concurrency record.

The role of the “session server” is to own the session table and periodically create a cleanup process. This is a low priority process that goes through the ets table using ets: next () calls and deletes expired sessions.

Please note that there are no timers.

Answer 4

You cannot be mistaken in any of the proposed solutions if you do not have a ginourmous number of sessions. And what I am saying is what you must compare.

The timer module is implemented as an ordered table ets, where ets: first you can efficiently find the first timer, which should expire and sleep until this happens. Thus, there is no problem adding many thousands of timers through the timer module. One per session.

If you have so many sessions, the fault-tolerant design problem is probably the more serious problem. You will need to distribute your session database so that the requests can be load balanced and you are not vulnerable to any one web server machine.

And that’s how I feel that it can be without functional requirements.