With sessions in a shared database, you shouldn't need sticky sessions, as the sessions are accessed in one central location. Not sure why it's not working in this case, but it bears further investigation.
Anthony On Friday, October 24, 2014 5:41:06 AM UTC-4, Louis Amon wrote: > > I am trying to scale up my application deployed on Heroku by increasing > the number of dynos and am currently confronted with the issue of handling > sessions in a distributed environment. > > The regular solution (storing sessions in the database) does not seem to > work anymore when multiple dynos run concurrently : clients get asked for > login at every request. > I have no idea why this doesn't work since databases are supposed to be > shared between dynos on Heroku, but as far as I know there are 2 possible > ways to manage scalable sticky sessions: > > > 1. Memcache : couldn't use gluon/contrib to test this because the > MemcacheClient does not allow authentication in a connection string (i.e. > services like Memcached, MemCachier...) > 2. Redis : same issue --> Redis client does not seem to work well with > auth-based services that are available on Heroku (e.g. RedisCloud) > > > > Any idea why db-based sessions do not stick out of the box on Heroku, > and/or how to use a Cloud-based service to achieve session stickiness ? > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
