On Sunday, April 1, 2018 at 8:18:39 PM UTC-4, Zsolt Ero wrote: > > Hi Jonathan, > > I'm not 100% sure I understand when are you talking about the > "standard" Pyramid way of the cookiecutter template's get_tm_session's > implementation and when are you talking about my special addition of > using the db to set up the app. >
I don't know why it was removed from the cookiecutter. It's been present in the cookbook and docs for years, see the cookbook: https://docs.pylonsproject.org/projects/pyramid-cookbook/en/latest/database/sqlalchemy.html I've opened a ticket on the cookiecutter to correct this. I don't know how and when is a gunicorn process fork happening in the > standard Pyramid app, but I presume it's tested and proven by people > who understand the internals of SQLAlchemy connections. By this I mean > that I think about request.dbsession as something which is managed for > me. This results in 1 idle connection per gunicorn worker. > It's not. SqlAlchemy, Pyramid and Zope.SqlAlchemy (the transaction extension) do nothing to check or manage this. Anything that is happening is pure coincidence and luck. If you connect to the database before the fork, you need to call `engine.dispose()` If you don't connect to the database before the fork, you don't need to call `dispose`. So far, my workaround which seems to work is the following: > > dbsession = config.registry['dbsession_factory']() > siteconfig = get_siteconfig(dbsession) > dbsession.close() > del dbsession > > (I'm deleting it to make sure that I cannot accidentally call it again). > > I tried calling dbsession.connection().engine.dispose() but it didn't > do anything. > > dbsession.connection().close() seems to behave the same as if I call > dbsession.close(). > I can try to spin up your test later. `dispose` is really what you need to call in your situation. `close` just 'ends' the session and returns the connection to the pool; `dispose` will close the actual db connection. (perhaps this is being done by the delete, i don't know). it is important to close the connection and reset the pool before the fork, because you run the risk of different workers using the same connection. -- 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/e5c2df72-f9b8-4de9-92e1-639e13e52391%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
