Yeah, it seems to me that if you pass a *specific connection* to a
sessionmaker for some (whatever) reason, that sessionmaker shouldn't ever
silently take a different one.
I'll need to work on detecting or sabotaging new connections from a
sessionmaker which was passed a specific connection. (I
On Wednesday, April 13, 2016 at 7:25:16 PM UTC-4, Mike Bayer wrote:
>
> Well scopedsession.remove throws away the session, so yeah either don't
> call that , or set up the connection immediately on the next session.
I thought "this is obvious, the session is closed on `remove`", but then
Will the connection.info dict always be new if a new
underlying raw connection has been grabbed? (Such that I can reliably
detect this situation?)
On Wednesday, April 13, 2016, Mike Bayer wrote:
> Well scopedsession.remove throws away the session, so yeah either
Well scopedsession.remove throws away the session, so yeah either don't
call that , or set up the connection immediately on the next session.
On Wednesday, April 13, 2016, Kent Bower wrote:
> About a year ago you helped me ensure my scoped session gets the same
> connection
About a year ago you helped me ensure my scoped session gets the same
connection to the database, which might be important.
I found out using "bind=connection" doesn't guarantee the session_maker
uses that connection if something went wrong with the session and
ScopedSession.remove() was called.
Thanks very much Mike.
On Monday, March 23, 2015 at 12:40:46 PM UTC-4, Michael Bayer wrote:
Kent jkent...@gmail.com javascript: wrote:
In cases where we interact with the database session (a particular
Connection) to, for example, obtain an application lock which is checked
out from