On Jan 2, 2014, at 9:38 AM, John Kida <[email protected]> wrote: > First let me make sure that I understand what the recycle parameter does in > the pool. Lets say I have a session i never close(), or even a query that > exceeds this recycle limit to return . When this recycle parameter limit is > reached the connection will automatically be closed removed from the pool, > and replaced with a fresh connection.
If you have a session you never close then recycle is not involved. The recycle setting only applies to connections that are not checked out, e.g. are waiting in the pool. When a checkout occurs, *then* the recycle timeout is checked and the connection is closed/reopened right then, and nowhere else. if you want to “recycle” a connection while its checked out, you’d need to call Connection.invalidate() which does this. Or, if you try to run a statement on the Connection, and it throws an error that indicates a “disconnect”, this exception is thrown, but the underlying connection is recycled in that case also. In all three cases, there’s no background thread replacing connections automatically. it is always the result of an explicit action, and it never implicitly replaces an existing transaction with a new one. > > If the above statements are true, I would like to use this parameter to > debug. I am not sure if anyone have used c3p0 from java land, but it has a > parameter unreturnedConnectionTimeout which i believe this is equivalent to > the recycle parameter. For debuging broken applications it allows you to also > set debugUnreturnedConnectionStackTraces which will print the stact trace of > what ever called this connection that was never returned. this feature isn’t built in but you can get at it on your own using events. Implement the checkout and checkin events and track stack traces for connections on your own. http://docs.sqlalchemy.org/en/rel_0_9/core/events.html#sqlalchemy.events.PoolEvents.checkout http://docs.sqlalchemy.org/en/rel_0_9/core/events.html#sqlalchemy.events.PoolEvents.checkin > This sounds similar to the AssertionPool, however i dont think this is what i > need. I am trying to figure out what connections are opened and never closed, > or possibly have a query so bad that its taking entirely too long to return > (long running queries can be found through the postgres long running query > log though). > > I was hoping someone could give me some advice on how I could debug which > calls in my application are causing the recycle limit to be hit. > > I am not sure i understand AssertionPool, or maybe it use case for debugging > just doesnt make sense for web applications backends but does for other apps. > If i understand correctly it simply throws anytime more then 1 connection is > used from the pool.. not sure I understand why you would use a pool if you > dont want your app to ever use more then 1 connection though. assertion pool is more for the use case of debugging an app that opens too many connections and causes deadlocks, often within a test suite that uses a different connection to emit queries as the one that is trying to tear down the tables, causing deadlocks particularly on postgres.
signature.asc
Description: Message signed with OpenPGP using GPGMail
