On Fri, Oct 27, 2017 at 11:55 AM, Sam Lee <skyn...@gmail.com> wrote: > I'm using scoped_session in a single threaded daemon that has infinite loop > and sleeps after each iteration. > It's only doing queries (does not write to db). > > I guess unit of work for this daemon is an iteration. > From what I'm gathering from documentation, I should create a Session for > each unit and close (and remove() in case of scoped_session to unregister) > when the unit is done. > > Session = scoped_session(...) > > while True: > try: > Session().execute... > finally: > Session.remove() > > > But, the program is actually doing: > > while True: > try: > Session().execute... > finally: > Session().rollback() > > with no problem. No increasing memory because Session() always returns same > object (thread local). > Only difference I can observe is that Session().rollback() throws exception > when database is unreachable during rollback but Session.remove() swallows > that exception.
OK not totally clear what your code actually says because your second example does not illustrate where this ".remove()" is present. > > Even in this type of program, is it better to always call Session.remove() > and get new Session object for each unit of work? calling .remove() has the advantage that any error state within the Session will definitely be gone. The Session tries to be recoverable from any error scenario if it is fully rolled back, but there could still be objects inside of it with problems, hence .close() solves that. Then, in even fewer cases, the Session might still be in a broken state (due to undiscovered SQLAlchemy bugs for example), so .remove() makes sure those are gone too. So, not critical to call .close() or .remove() but it gives you extra levels of resilience against failure modes that are not well covered. If you are only running session.execute() and not working with objects, it probably doesn't make any difference. > I'm trying to see if there's a down side of using same Session for life time > of application. > > > Thanks. > Sam > > -- > SQLAlchemy - > The Python SQL Toolkit and Object Relational Mapper > > http://www.sqlalchemy.org/ > > To post example code, please provide an MCVE: Minimal, Complete, and > Verifiable Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
