Teardown app context vs. request context #99

Closed
alexanderjulo opened this Issue Sep 3, 2012 · 7 comments

Comments

Projects
None yet
7 participants
@alexanderjulo

According to L672 flask-sqlalchemy uses teardown_appcontext if available and not teardown_requestcontext. I would actually like to know what thought was behind this, as the sqlalchemy docs suggest to close/remove/rollback the session after every request (see http://docs.sqlalchemy.org/en/rel_0_7/orm/session.html#lifespan-of-a-contextual-session).

In my opinion this can lead to problems with pool_recycle as not all connections are always returned to the pool (at least my sqlalchemy log looked like it) and so the pool won't be recycled. But I might be wrong.

@mgax

This comment has been minimized.

Show comment Hide comment
@mgax

mgax Jan 2, 2013

Contributor

When handling a request, the app context has a similar lifecycle to the request context, so tying the session to the app context makes sense.

Contributor

mgax commented Jan 2, 2013

When handling a request, the app context has a similar lifecycle to the request context, so tying the session to the app context makes sense.

@georgexsh

This comment has been minimized.

Show comment Hide comment
@georgexsh

georgexsh Nov 29, 2016

When handling a request, the app context has a similar lifecycle to the request context

@mgax I think this is not true, RequestContext.pop will not pop app context stack if the request is handled within an existing app context.
@immunda as you are the current active maintainer, would you like review this issue again?

georgexsh commented Nov 29, 2016

When handling a request, the app context has a similar lifecycle to the request context

@mgax I think this is not true, RequestContext.pop will not pop app context stack if the request is handled within an existing app context.
@immunda as you are the current active maintainer, would you like review this issue again?

@ngaya-ll

This comment has been minimized.

Show comment Hide comment
@ngaya-ll

ngaya-ll Mar 14, 2017

Flask's own documentation about SQLAlchemy integration recommends using teardown_appcontext.

ngaya-ll commented Mar 14, 2017

Flask's own documentation about SQLAlchemy integration recommends using teardown_appcontext.

@lepture

This comment has been minimized.

Show comment Hide comment
@lepture

lepture Apr 13, 2017

@davidism I think we should do session.remove() in teardown_request, so that session in every request is clean.

lepture commented Apr 13, 2017

@davidism I think we should do session.remove() in teardown_request, so that session in every request is clean.

@davidism

This comment has been minimized.

Show comment Hide comment
@davidism

davidism Apr 13, 2017

Collaborator

Commented on this in #379 (comment).

I'm going to need an example of how to run Flask in such a way that the same app context is reused for multiple requests (not for multiple manual request contexts within a single app context or test, but for actual requests). I can't reproduce this error and using the app context should be correct. The app context is for global app state during an interaction (such as a request or cli command).

Collaborator

davidism commented Apr 13, 2017

Commented on this in #379 (comment).

I'm going to need an example of how to run Flask in such a way that the same app context is reused for multiple requests (not for multiple manual request contexts within a single app context or test, but for actual requests). I can't reproduce this error and using the app context should be correct. The app context is for global app state during an interaction (such as a request or cli command).

@lepture

This comment has been minimized.

Show comment Hide comment
@lepture

lepture Apr 14, 2017

@davidism Yes, you are right. App context is the same as request context.

lepture commented Apr 14, 2017

@davidism Yes, you are right. App context is the same as request context.

@georgexsh

This comment has been minimized.

Show comment Hide comment
@georgexsh

georgexsh Jun 22, 2017

oh, I see, since I am using Flask-Script as entry point, a new app ctx object will be pushed to stack at the very beginning(ref 1), then there will no new app ctx object be created when handling new request(ref 2), all within the same outermost app context, as a result,teardown_appcontext wont be triggered pre-request(ref 3).
stating app context is the same as request context sounds wired to me, if this is true, why bother to distinguish two context stack, apparently they are not.
nevertheless, if we agree that database transaction should be isolated pre request, then teardown_request should be used here.

oh, I see, since I am using Flask-Script as entry point, a new app ctx object will be pushed to stack at the very beginning(ref 1), then there will no new app ctx object be created when handling new request(ref 2), all within the same outermost app context, as a result,teardown_appcontext wont be triggered pre-request(ref 3).
stating app context is the same as request context sounds wired to me, if this is true, why bother to distinguish two context stack, apparently they are not.
nevertheless, if we agree that database transaction should be isolated pre request, then teardown_request should be used here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment