Funny behaviour of MySQLdb

[Skip Montanaro]

    Alex> If MySQLdb.threadsafety >= 2, and there are no errors in your
    Alex> implementation, you're supposed to be safe.  

I just checked the docs for MySQLdb.threadsafety (version 0.9.2).  It's
value in that version is 1.  About this the docs says:

    The MySQL protocol can not handle multiple threads using the same
    connection at once....

    You can certainly do things like cache connections in a pool, and give
    those connections to one thread at a time. If you let two threads use a
    connection simultaneously, the MySQL client library will probably
    upchuck and die.  You have been warned.

I think this means I'm safe.  I do precisely what the second paragraph
suggests, cache several connections in a pool and give them out to one
thread at a time.

    Alex> If each "chat" is complicated enough and can't easily be
    Alex> encapsulated as a callable, you may even have some advantage wrt
    Alex> the architecture I'd consider even safer -- five dedicated
    Alex> threads, one per connection, all waiting for work requests on a
    Alex> single queue and returning results on a separate queue per
    Alex> requestor thread: you're saving a few resources by having 5 fewer
    Alex> threads and many fewer Queues around.

Each time I .get() a connection from the pool, I do tend to execute multiple
SQL statements.  Using a fixed numbers of threads associated with each
connection is a bit more complicated, especially since I already wind up
with a thread per request courtesy of SocketServer.ThreadingMixin.  Why
waste it? <wink>

    Alex> But the moment problems should start appearing, good luck.  

Well understood.  I was really quite surprised that I had very few problems
as I added locks to the shared objects when I converted the server from
single to multiple threads.

Skip