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
In cases where we interact with the database session (a particular
Connection) to, for example, obtain an application lock which is checked
out from database for the lifetime of the database session (not just the
duration of a transaction), it is important that I guarantee future scoped