On Tue, Jun 8, 2021, at 11:18 AM, 'Matt Zagrabelny' via sqlalchemy wrote: > Hi Mike, > > Thanks for the reply! > > On Mon, Jun 7, 2021 at 6:08 PM Mike Bayer <[email protected]> wrote: >> __ >> ORM Sessions ride on top of connections, but since the Session under it's >> default pattern of being bound to an Engine does the "connect" internally, >> it's probably inconvenient to adapt the optimistic disconnect approach to >> it. You would probably want to bind the Session to the Connection >> explicitly. > > I searched the SA docs, but could not find how to bind the Session to the > Connection.
you just pass the Connection as the "bind" argument to Session, there's an example of that here: https://docs.sqlalchemy.org/en/14/orm/session_transaction.html#joining-a-session-into-an-external-transaction-such-as-for-test-suites > >> however, I would advise using pool_pre_ping instead which is much easier >> to use and has basically no downsides. this feature didn't exist when the >> docs for "optimistic disconnect" were written. > > Sure. I was only looking at doing the optimistic disconnect because it seemed > a little more resilient to failures (if a DB error happens mid transaction) > and because I felt I could control the number of retries and put in an > exponential backoff. > > Do you suggest I use the custom pessimistic ping code: > > https://docs.sqlalchemy.org/en/14/core/pooling.html#custom-legacy-pessimistic-ping > > to add in exponential backoff or add additional retries? what's the real-world use case where exponential backoff is useful? do you expect databases to be shut down for a number of minutes without disabling the application ? The "optimistic" approach inherently involves having a request fail with an exception in any case, which suggests you aren't going for a "shut down all the databases for minutes, nothing fails" kind of use case. having a full retry-nothing-fails approach typically involves having "retry" at the level of your entire operation, not at the point at which it first connects. that said, sure you can build "exponential backoff" into the pessimistic ping recipe, it just seems like a lot of effort for a solution that's incomplete in any case. > > Thank you again for the help! > > -m > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/CAOLfK3WYSinbhQLbMaBTf7sRRDZ8PtVcQ6u2-gV4ftjS36ZstA%40mail.gmail.com > > <https://groups.google.com/d/msgid/sqlalchemy/CAOLfK3WYSinbhQLbMaBTf7sRRDZ8PtVcQ6u2-gV4ftjS36ZstA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/a4d34edd-7cc1-466a-81c4-d19891b2b625%40www.fastmail.com.
