On Wednesday, October 24, 2018 at 9:01:53 PM UTC-4, Mike Bayer wrote: > > that's not normal unless you are holding a Connection around and > calling close() on it, have a stack trace ? or is this inside an > event handler? >
First, *a huge thanks for everything.* This had been troubling me for hours and put me in a tailspin. session.commit() you mean, yes this is normal if the Session is bound > just to an engine. if you bind the Session to a specific Connection > then it will keep using the same connection. > binding the session to a specific connection might be a good fix for me. I think I can probably write something that can replace an "engine" session with a "connection" version of itself. > That seems strange ? the order should be, checkout, engine_connect, > commit, reset, checkin, > strange indeed! i had some typos and logged 'checkin' for 'checkout', etc. all fixed now and logging correctly. > update....what exactly? > I was thinking about updating the connection in each object's session. that doesn't seem to make sense in retrospect. I dug deeper into this problem, and nothing made sense. I have things working now, but I'm not sure how/why. * `close()` doesn't get called until a cleanup phase, which happens after the exception is raised. I had checked the source and added debug log lines to be sure. * i read some lines wrong, and the problem wasn't on a lazyloaded SqlAclhemy relationship, but on a lazyloaded relationship in the read-through dogpile caching layer -- which was modeled after SqlAlchemy. The general issue seems to have been this: * A new Pyramid request creates a new SqlAlchemy session container, `dbSession`. this contains two possible sessions - "reader" and "writer". * Some data is queried directly from SqlAlchemy, some other data is queried via primary key from a readthrough dogpile cache, which falls back to the dbSession on a cache miss. * the dogpile objects have a `lazyloaded function` which lets them load a related object on demand, preferably from the cache but falling back to SqlAlchemy After one or two calls to `commit()`, the I was losing a session connection. postgres logs don't show anything weird. sqlalchemy doesn't show anything weird to me. I tried keeping some objects queried from the session on hand, in case it was a garbage collection issue; no luck. after a whole lot of testing and looking at source, i noticed 2/9 cache calls in the 'writesafe' module were using the 'reader' connection instead of the 'writer' connection - this cache region has a 90second expiry and does a first check on permissions to avoid locking/transaction issues. switching the Session to use the writer -- fixed the problem, but I have no idea why. It makes even less sense. -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
