+1 on anthony. Dynos are meant to scale as "serving frontends". The data(base) that a dyno1 sees NEEDS to be the same data(base) dyno2 sees, or the whole concept of consistency is not assured (and there's little point of being "distributed" when the only consistency is assured by having a replicated static content). Being distributed doesn't mean being scalable by default. Being "easily" scalable needs consistency at infrastructure level, and that's what - supposedly - Heroku gets paid for.
PS (on redis issue): I'm working towards a small rewrite of redis_cache and redis_session that will avoid having separate methods (and limited to the implementation of redis that was available at the time), with the added bonus of NOT requiring a separate connection for cache and session. That'll solve the issue because - ideally - if you can use service xyz with the redis library, you'd need to be able to use that in web2py too. -- 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.
