15

What are the different use cases of Rack::Session::Pool and Rack::Session::Cookie?

As far as I understand (correct me if I'm wrong):

  • Cookie stores all the session key:value pairs directly within the cookie (marshalled)
  • Pool only stores an id in the cookie, and maintains the rest of the session hash within @pool

So: what are the implications/reasons for choosing one over the other? what's @pool? Why does Pool need to expose a different public interface from Cookie? Why is the documentation so lacking?

Ross Attrill
  • 2,594
  • 1
  • 22
  • 31
pje
  • 21,801
  • 10
  • 54
  • 70

1 Answers1

15

You are right, Session::Cookie marshaling and store sessions in cookies.

Session::Pool instead keeps sessions in memory.

Pool has some advantages:

- faster, no marshaling needed 
- you can keep any objects with it(read ones that can not be marshaled)

But when you restart your app all sessions are lost.

With Cookie instead you will have restart-persistent sessions at the price of marshaling.

Alternatives - Session::Memcache, Session::Mongo

Ross Attrill
  • 2,594
  • 1
  • 22
  • 31
  • 1
    Rack::Session::Moneta: http://www.rubydoc.info/github/minad/moneta/Rack/Session/Moneta also provides an abstract session store interface to a large variety of key/value stores – Ross Attrill Nov 05 '14 at 22:09