On Thursday, March 24, 2011, 12:33:37 AM, Michael Bayer wrote: > the pool_timeout parameter manages this from a client perspective, > in that a stale connection won't be used. An application with a > decent amount of activity should clean these connections out > regularly as they are closed the moment they are called up from the > pool, and have passed their expiration time (if you aren't observing > that, that's another bug).
Yes I understand, some database connection pooling implementation in java does have a functionality to enable programmer performing some task to verify connection just after it checked out from the pool. However, in my case this could be considered a rare situation in which i could put this issue on a lower priority. > If you're designing for the use case that the application is doing > absolutely nothing for hours, then yes the stale connections will > just sit there. but I would think that an app with such little > usage would only have a few connections checked out anyway and these > are of no consequence. My application currently serving about 200-250 users only. However some of them does performing intensive tasks which by this SA Pool would automatically opening new connection to serve other user request. Total number connection actived in the pool could reach 20 connection. These 20 connection would kept in idle state in the pool for hours (night) until another request being made tommorow morning and those connection recycled one by one. Indeed 20 connections is not a large number, but after few days running, the database server complains not enough bufferpool to serve another application. However I might be biased on this, I believe those issue is more related to unclosed overflow connections rather than this case. > If you really want to sever the TCP link proactively expecting a > totally idle application, I'd look into getting the database server > to perform this severing (such as what MySQL does automatically > after 8 hours). Yes, however not all database have this functionality. afaik, db2, and firebird does not. -- Salam, -Jaimy Azle -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
