>>>>> "Scott" == Scott Weikart <scott@stripped> writes:
Scott> Here's the MyODBC maintainer's comments on threads:
Ales> is libmyodbc thread safe or I should wrap ODBC functions with mutexes?
Ales> I wrote a simple test program where 2 threads share ODBC environment
Ales> and connection and within their bodies thay keep running in loop doing
Ales> SQLAllocStmt,SQLExecDirect,SQLBindCol,SQLFetch and SQLFreeStmt. It
Ales> crashes within tens
Ales> of seconds. However, if I wrap SQLExecDirect with a mutex then the test
Ales> seems to run
Ales> without problems. Where can I find out which functions from libmyodbc
Ales> safe to use directly within a multithreaded program?
Scott> The MyODBC is thread safe if you use different connections. If two
Scott> threads access the same connection at the same time anything can
Scott> As MyODBC reads all results sets into memory, it 'should' be thread safe
Scott> if you have a mutex around SQLExecDirect.
>> We can prevent Cold Fusion from crashing by making it use only one connection
>> at a time, but the results are unacceptable. Essentially Cold Fusion will
>> run out of connections it can queue and then users will be denied even though
>> CF is still running.
Scott> When you had crashes *before* you restricted CF to one connection, did you
Scott> often get registry corruption? We have crashes every few weeks that involve
Scott> registry corruption, but I never associated them with MyODBC.
Scott> Also, our CF load is very low.
>> Do you foresee a multithreaded ODBC driver for MySQL in the near future?
Scott> I'm not one of the maintainers; I just helped with the port to Solaris 2.6 .
Scott> The primary maintainer is Monty, who's also the primary maintainer of MySQL.
Scott> Go to http://mysql.he.net to find out details.
As MySQL has a very low overhead for connections, it's better to use a
different connection for each thread. This will also give you better
performance than if MySQL would share many threads on the same