0

I'm looking to implement sessions for a web server that I'm developing in my free time. Currently, it had cookie support, so users could implement their own session management, but this is something that should be handled by the web server. I'm faced with two secure options:

  • Store it in memory, and expire the session if the user does not make a request over a certain amount of time. This has the advantage of speed; accessing the memory is fast. It's also easier to implement, but this is a non-concern.

or

  • Store it in a database of some sort, and expire the session if the last_access time is over a certain amount of time. This has the advantage of persistence; a server shutdown, restart, etc. will not impact this. It would also be possible to use a database on another server for this purpose, allowing multiple servers to share sessions (e.g. for load balancing).

I'm trying to decide whether keeping sessions over a restart or shutdown is important enough to sacrifice the speed of storing it in memory, or whether I should simply cache sessions and store them in a database of some sort as a "backup", e.g. in the event of a crash or a restart, I would restore sessions (if they're not expired) from the database. Edit: This is in a single-threaded environment. It's not an option to multithread it.

From the perspective of the user of the web server, which is more important? Speed, or persistence?

Improve this question
2
  • 2
    Are you planning on load balancing your application? If so then it basically rules out the first option? Also how much data do you need to store in your session? You're missing a 3rd option of cryptographically signed or encrypted client side cookies.
    – thexacre
    Apr 4, 2015 at 23:32
  • 1
    For what it's worth, sessions are considered an old design; modern, stateless HTTP and REST-style applications should not need sessions at all, if they're designed properly.
    – Robert Harvey
    Apr 5, 2015 at 1:27

1 Answer 1

Reset to default
2

Why not both?

I suppose you want a quick turnaround, without waiting for the session to get stored in the database. But this does not prevent you from putting the data into the database eventually, because probably users do not register a new session at every request for prolonged periods.

I'd have an in-memory cache of a limited size, a queue, and a database. When a new session is registered, it stays in the cache and is put into the queue. A background thread keeps reading the queue and putting the new sessions into the database. (Another background process would periodically expire them.)

Session creation and reuse stays instant: immediately following requests find the session in the cache and don't hit the database at all. Requests for the same session a week later probably will not find it in the cache, and will hit the database once, populating the cache.

Of course it is possible to overpower this scheme by registering so many sessions so fast that most requests will be unable to find recently-created sessions in the cache, and won't find the data in the database, because the database will not keep up with the queue. But without the cache + queue, even a smaller amount of request would kneel the server.

Improve this answer
1
  • I like this idea. This could also be modified slightly to overcome the problem of vanishing sessions due to a huge cache usage. 1. Write session to database right after login. 2. When user makes the next request, check if you can find that from cache. 3. If not, check from the database. If you find it there, do the following: i. refresh cache expiration time by, say, 10 minutes, ii. store the session information in the cache, so you'll find it next time without a need for an expensive database trip. This effectively gives you the ability to store sessions without querying database too often.
    – sankari
    Apr 5, 2015 at 0:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.