heres the bug fix:
--- lib/sqlalchemy/pool.py (revision 1540)
+++ lib/sqlalchemy/pool.py (revision 1541)
@@ -71,7 +71,7 @@
class Pool(object):
def __init__(self, echo = False, use_threadlocal = True,
logger=None, **kwargs):
- self._threadconns = {} #weakref.WeakValueDictionary()
+ self._threadconns = weakref.WeakValueDictionary()
On May 28, 2006, at 3:22 PM, Valentino Volonghi aka Dialtone wrote:
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
-------------------------------------------------------
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
