On Monday, April 2, 2018 at 12:09:26 PM UTC-4, Zsolt Ero wrote:
> So if I understand right, the engine in a gunicorn / process worker > Pyramid app is global / shared between all processes, right? And at > the time of forking, there should be no dbsessions being active and no > connections in the connection pool, right? > Sort of. I'll try to explain this simply and using terms closer to you. The engine is global but you DON'T want to share it between processes because of Python's copy-on-write behavior and how connections are handled as file-descriptors. When each process creates a new connection (or otherwise updates the pool), the pool is basically copied into a per-worker variable then updated. If you have active connections in the pool *before* the fork, everyone gets a copy of that connection and thinks it is theirs -- but if the pool is empty, everyone gets an empty pool. > Where is the forking happening in a normal Pyramid app? After the main > function finishes / "return config.make_wsgi_app()"? > Somewhere after there, i believe. It depends on the server. uwsgi and unicorn do it in different places. i think waitress essentially does it too. gunicorn offers a post_fork hook (http://docs.gunicorn.org/en/stable/settings.html) which you can use to trigger a dispose. If you connect within the __main__ to pull config settings out of the db, you generally want to immediately drop the connection. Doing it within your startup routine and before the fork is fine - but you can also do it after the fork. All that matters is that the engine is disposed before you use it. I'm checking with SqlAlchemy, but it looks like `dispose` doesn't explicitly close the session - it just removes it from the connection pool which will effectively close it during garbage collection. calling close()+dispose() in your startup should be fine. there's another technique to protect against forks that mike (bayer of sqlalchemy) has been using in openstack and may bring to the main project, but I'm not sure if/when that will happen. if you think you may jump between platforms and use multiple libraries/patterns that aren't fork-safe, I wrote a library that turns uwsgi & gunicorn events into subscribers (https://github.com/jvanasco/pyramid_forksafe) that make the cleanup work a little more portable. We use sqlalchemy, pymongo and pycrypto which are all not forksafe. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/82a9fae4-2fe5-452e-8388-68007f8c2c6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.