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 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.
So if I only want to solve my addition and not touch the standard
design of request.dbsession, what would I need to do?
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().
Does this sound as a reasonable solution? It seems to fix my problem,
I just want to know if I'm doing anything wrong here.
Zsolt
On 2 April 2018 at 01:58, Jonathan Vanasco <[email protected]> wrote:
> Pyramid isn't opening the database connection, the SqlAlchemy pool is.
>
> On first glance, you're connecting to the database in your main(). This is
> guaranteed to create issues with SqlAlchemy's connection pool when you
> involve multiple workers/threads/processes. In some situations the
> connection gets reused by multiple processes, in others it gets lost.
>
> The proper way to fix this is to call `engine.dispose()`
> [http://docs.sqlalchemy.org/en/latest/core/connections.html#engine-disposal]
> either immediately after you use it, or in a post-fork hook.
>
> I also don't see an add_finished_callback registered to call
> 'session.close() on every request (or at least the ones where you grab a
> dbsession), or the close() being called in any other way (like a tween).
>
> Between both of those traits, you're going to have a connection pool that
> constantly needs new connections (it has to wait for python's GC to clear
> out the connection), and might re-use existing connections unreliably.
>
> There could be other factors causing this too, but you should integrate a
> `dispose` after the app starts and add a utility to register a
> session.close() via add_finished_callback(). If that doesn't solve it,
> there are a lot of docs in SqlAlchemy on the connection pool specifics.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pylons-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pylons-discuss/_MJflNUcjdg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/d21f0d7e-f20c-4760-9e03-9e057dde376c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/CAKw-smAeZFzLUeAB00WWXd%3DJWi1c1eMkAXxkJtKYeKJBzOx%2BzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
