On Sep 30, 2005, at 8:36 AM, Ian Bicking wrote:
Kevin Dangoor wrote:
Hi David,
Sorry I hadn't gotten to your message on the SQLObject list.
You're reading things correctly... Luckily, the fix should be simple.
Currently, the AutoConnectHub is specifically working around caching
the SQLObject does in connectionForURI, because that caching is not
compatible with sqlite. I'll just change the hub so that this
workaround is *only* there for sqlite.
I've been thinking about this... but only lightly which is why I
haven't done anything about it. Anyway, I think the bug is
elsewhere; all your requests should share a single SQLObject
connection, unless you are using transactions for each request
(?). However, SQLObject may not be respecting the threadsafety of
SQLite. It seems vaguely that SQLite doesn't want you to ever
share connections between threads, even though SQLObject passes
connections about and just doesn't use a connection simultaneously
from two threads...?
This sounds like what I've wound up doing, though I'm still not
completely satisfied with the results. In my case I'm using
PostgreSQL with psycopg, so multiple threads connecting to the
database is OK. What I was worried about is the SQLObject CacheSet
object caching. Since it's tied to a connection, if I establish a one-
to-one thread to db connection policy then I have many CacheSets, and
certainly cache a single object many times. At best this is
inefficient, at worst it seems like I can run into data consistency
problems.
I'm experimenting now with a modified AutoConnectHub that always uses
a shared connection, but will create a new thread-local one when a
transaction is started (and dispose of it when the transaction is
done). I don't fully grok how this will work out when touching object
that have cacheValues = True, but I'll keep reading the code ;-)
-- David
