On Dec 11, 2007, at 5:53 PM, imgrey wrote:
> > 2007-12-12 00:19:24,099 INFO sqlalchemy.pool.QueuePool.0x..90 Created > new connection <connection object at 0xda9bd0; dsn: 'dbname=df > host=localhost user=grey password=xxxxxxxx', closed: 0> > 2007-12-12 00:19:24,099 INFO sqlalchemy.pool.QueuePool.0x..90 > Connection <connection object at 0xda9bd0; dsn: 'dbname=df > host=localhost user=grey password=xxxxxxxx', closed: 0> checked out > from pool > > 2007-12-12 00:31:08,901 INFO sqlalchemy.pool.QueuePool.0x..90 Created > new connection <connection object at 0x180cad8; dsn: 'dbname=df > host=localhost user=grey password=xxxxxxxx', closed: 0> > > repeated 15 times > your s.close() is not being reached, if theres no connection closes happening, or some other part of your app is opening connections and not closing them. put a big "print" statment after your s.close() to make sure its being called. You can check that theres not an exception being thrown and silently caught elsewhere that buries it, that the thread doesnt go on forever without reaching the close. You can also put the s.close() is in a finally: block so its guaranteed to be called in the event of a thrown exception. if you have a deadlock situation occurring, that can also quickly cause many connections to remain opened, all waiting on the same lock. if youre locking rows and such, you have to be careful that other transactions dont try to lock the same rows in a different order. by "different transactions" this could be a trans in the same thread, or in a different thread, and youll have to narrow down which. if youre stiill doing that thing where you delete a row and then immediately re-insert it, i will ask again that you consider using an UPDATE instead. locking, either database locking or mutex locking, is usually discouraged for this reason although your app seems to require it based on what it has to do. if you want to nail down a deadlock in python, theres a module called "threadframe" ( http://www.majid.info/mylos/stories/2004/06/10/threadframe.html ) which I recommend for that. have your script run for some number of seconds to the point where its clear that the deadlock has occured (typically using a time.sleep() call to wait), and then have it run threadframe, printing out the full stack. you'll see where all the threads are waiting, and typically there will be one or threads in the list which are in a visibly different stack trace than all the rest and you'll be able to trace out the origin of the issue. > > Btw, there's another problem: application opening maximum allowed > files, so > other services is dying. And I'm suspecting sqlalchemy, because > there's only > one place in my code where file is opening, followed with file.close() its probably a side effect of 300 connections being opened. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
