If you are running a Rails 3 app with multiple web dynos on Heroku,
In short yes - sessions will work across multiple web dynos.
Sessions work across web dynos - because Rail's design of session support allows it to. If anything, the web dyno model is exactly how Rail's was intended to be scaled horizontally.
1. Every time you hit the app, do you typically connect with a different web dyno?
Based on heroku documentation:
The routing mesh is responsible for determining the location of your application’s web dynos within the dyno manifold and forwarding the HTTP request to one of these dynos. Dyno selection is performed using a random selection algorithm.
So dyno selection is random... but that dyno has to have your application installed. So if you have more than one dyno, then you may end up connecting to a different dyno (which is important as this facilitates load balancing and high availability)
2. Can sessions work across different web dynos?
Yes. Most web stacks support sessions by doing the following:
So by this process, sessions can be supported as every inbound HTTP request has the session ID, which is accessible by the web dyno when it handles your request.
3. Does it work for different Rails session stores (ActionDispatch::Session::CookieStore, ActiveRecord::SessionStore, and ActionDispatch::Session::CacheStore)
ActionDispatch::Session::CookieStore Yes. The cookie store stores encrypted session data as a cookie. So your browser sends all the session data (encrypted) back to the host, which is then decrypted for use within your app.
ActiveRecord::SessionStore Yes. The cookie store stores encrypted session data in a database table. An ID is then assigned as a cookie. So your browser sends the ID to the host, which is then used to load the session data from the database. Since all web dynos have a connection to the DB, this means it is also supported.
ActionDispatch::Session::CacheStore Yes but you need a cache store service (eg MemCache addon). The cookie store stores encrypted session data in a cache store (memcache), which is a shared service across all web dynos. An ID is then assigned as a cookie. So your browser sends the ID to the host, which is then used to load session data from the cache store (memcache).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With