session.close() vs. rollback or commit

[Sam Lee]

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.

Even in this type of program, is it better to always call Session.remove() and get new Session object for each unit of work?
I'm trying to see if there's a down side of using same Session for life time of application.


Thanks.
Sam

[Mike Bayer]

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+...@googlegroups.com.
> To post to this group, send email to sqlal...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/d/optout.

[Sam Lee]

Thanks. I was comparing Session.remove()  vs. Session().rollback().

So, since I'm not using objects (as in orm), but only use Session().execute(), it's okay to use .rollback() instead of .remove().

But, it's better to use .remove().

I think it's clear now. Thanks

> email to sqlalchemy+unsubscribe@googlegroups.com.

> To post to this group, send email to sqlal...@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 a topic in the Google Groups "sqlalchemy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy/jyeMsrdDGsg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sqlalchemy+unsubscribe@googlegroups.com.