I am not saying i will not use try: finally: rollback. I am building a framework and if a little tiny feature in a project that uses the framerwork that opens a transaction and will not use try finally: means that 100 customers are going to be locked out because of the resource leak, it does not seem reasonable.
Anyway, if i believe there is a bug i am reporting it in case other bugs follows. I have tried what you described with and without threadlocal, and with explicitly deleting every object i can find, like the transaction, session etc... and it does not release the connections. Btw: The db engine,mapping,metadata are defined and exists persistently outside the threads. Sessions and transactions are created inside threads. The threads are destroyed immediately after transaction creation (and running a little select query as i described in previous mails). Also, just to be on the safe side :), one thread is sleeping for 60 secs and then try to repeat the transaction creation etc... just to make sure if SQLAlchemy needs to do anything active to release the connection. On Saturday 05 August 2006 03:47, Michael Bayer wrote: > actually, all connections that are freed by the pool have a rollback > () called on them automatically. > > also, connections are returned to the pool when the proxying object > of the connection has its __del__ method called, so the behavior you > want is already there. if you lose all references to a > SessionTransaction as well as the Session its associated with, when > they get garbage collected, so will all connections theyre holding > onto, and the connection will be returned to the pool (and the > rollback() will be performed). assuming your engine is not using the > "threadlocal" strategy. > > if you are using the "threadlocal" strategy, not as simple; the > engine is holding on to the current transaction associated with the > current thread; its by design that you dont have to hold on to any > transactional object, and the transaction remains open, until > explicitly committed or rolled back (which can be performed directly > off the engine in the case of 'threadlocal'). > > if you want very explicit management of resources, not using > "threadlocal" for your create_engine() strategy, using "default" > instead, is the first step. > > also, even though the functionality you want is present, it strikes > me as a poor practice to use a SessionTransaction without a try:/ > finally: block that explicitly calls rollback() or commit() on it. > I cant think of a reason youd want to begin a transaction and then > just let it fall away without managing its closure; it seems to > defeat the purpose of a transaction, which is, demarcation of a set > of operations. -- Regards, Tzahi. -- Tzahi Fadida Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info WARNING TO SPAMMERS: see at http://members.lycos.co.uk/my2nis/spamwarning.html ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
