On Sun, 28 May 2006 15:10:37 -0400, Michael Bayer <[EMAIL PROTECTED]> wrote:
if you are having deadlocks within one thread, that is almost certainly because you are using two simultaneous connections from the database, one of which has a lock on a table (due to a transaction) which the other is trying to reach. if you are using a plain strategy='default', this is a
This is for sure. But I'm only dealing with one connection per thread.
very likely thing to happen since each call to connect(), as well as contextual_connect(), returns a distinct connection from the pool.
Indeed. That's why I think it's weird that using plain fixes everything while using threadlocal doesn't. The reason IMHO could be that sqlalchemy doesn't actually commit the transaction when I ask for it.
using QueuePool with "threadlocal=True" should eliminate this problem as long as you are operating within one thread. there is a unittest which has always passed for this in test/pool.py, testthreadlocal_del and testthreadlocal_close, which insures that multiple connections pulled from a threadlocal pool in the same thread are in fact the same connection. also, if you create_engine() with strategy='threadlocal' and deal with contextual_connect(), it should also be using QueuePool with threadlocal....i just added a test for that and it passes (also unsetting the 'threadlocal' flag on the pool makes it fail which verifies the test).
And indeed I was aware of this (read from the documentation).
if you use strategy='threadlocal' and use the TLEngine in exactly the same way you did with 0.1, i.e. there is no explicit Connection object and you just call execute()/begin()/commit() off the Engine directly, im pretty sure it should now be exactly the same. if you use explicit Connections only with TLEngine, that should work pretty well at the moment also. if you mix both approaches, i.e. explicit Connections with begin()/commit() calls on the Engine directly, that still might get screwed up.
I tried changing back the code and using threadlocal strategy but nothing changed.
without my having to learn twisted in one day, let me ask you this: 1. does your application use mutliple threads or just a single thread ?
Multiple threads.
2. do you wish for your application to use a single PG connection throughout, or are you trying to manage mulitple connections in one thread ?
One connection per each thread but I actually never cared about this detail since I always relied on sqlalchemy dealing with this stuff for me in the right way.
I might add that in SA0.1 it was pretty much impossible to have multiple connections in one thread unless you were playing with push_session()/pop_session()...
In fact I was not because I didn't cared at all. In the current situation I think there is always one transaction open per connection even if it should have been committed. ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
