I've been looking into it a bit more.

I _think_ when a dbsession is deleted / garbage collected, it is
closed. And transaction.manager / pyramid_tm is making each session
garbage collected after each request, isn't it? Thus
add_finished_callback is implemented in SQLAlchemy side, at least this
is my idea.

Where is the forking happening in a normal Pyramid app? After the main
function finishes / "return config.make_wsgi_app()"?

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?

So the super safe code for init time db lookup is this?

# dbsession, siteconfig
dbsession = config.registry['dbsession_factory']()
siteconfig = get_siteconfig(dbsession)
dbsession.close()
dbsession.connection().engine.dispose()
del dbsession

Zsolt


On 2 April 2018 at 17:54, Jonathan Vanasco <jvana...@gmail.com> wrote:
> 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 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
> 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.

-- 
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/CAKw-smBiwQsy6S%3D%2BptJ6SRd4ddBCzB4R-9a5e_2k03%3Du4hr_wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to