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 <clas...@zzzcomputing.com> 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. > > On Wednesday, April 13, 2016, Kent Bower <k...@bowermail.net > <javascript:_e(%7B%7D,'cvml','k...@bowermail.net');>> wrote: > >> 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. Is there a way to guarantee this? >> >> See attached script that fails on version 1.0.12 >> >> Is this the intended behavior when sessionmaker has a specific connection >> as bind? >> >> >> >> On Mon, Mar 23, 2015 at 12:40 PM, Michael Bayer <mike...@zzzcomputing.com >> > wrote: >> >>> >>> >>> Kent <jkentbo...@gmail.com> 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 database for the lifetime of the database session (not just the >>> duration of a transaction), it is important that I guarantee future scoped >>> session instances get the same connection (and, for example, the >>> pool_recycle or something else has thrown out that connection and grabbed a >>> new one). >>> > >>> > Please advise me where I can best implement this guarantee. A Session >>> subclass's connection() method seems it might be the appropriate place, but >>> let me know if there is a better recipe. >>> >>> you’d want to create that Session associated with the Connection >>> directly: >>> >>> my_session = scoped_session(bind=some_connection) >>> >>> then of course make sure you .close() it and .close() the connection at >>> the end of the use of that session. >>> >>> >>> >>> > >>> > The Session.connection() method's docs say: >>> > "If this Session is configured with autocommit=False, either the >>> Connection corresponding to the current transaction is returned, or if no >>> transaction is in progress, a new one is begun and the Connection returned >>> (note that no transactional state is established with the DBAPI until the >>> first SQL statement is emitted)." >>> > >>> > If the session is one registered in my scoped registry, I'd like to >>> always return the same connection to guarantee I am using the one with the >>> database-side checked-out application lock. >>> > >>> > What's my best option? >>> > >>> > Thanks much! >>> > >>> > -- >>> > 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 http://groups.google.com/group/sqlalchemy. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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/WcdRsvBTozk/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> sqlalchemy+unsubscr...@googlegroups.com. >>> To post to this group, send email to sqlalchemy@googlegroups.com. >>> Visit this group at http://groups.google.com/group/sqlalchemy. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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. >> > -- > 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/WcdRsvBTozk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sqlalchemy+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','sqlalchemy%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to sqlalchemy@googlegroups.com > <javascript:_e(%7B%7D,'cvml','sqlalchemy@googlegroups.com');>. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- 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.
