Thanks for the reply. Just to confirm, from reading the link, if I use
store/store_next, I can give the StoreQueryResult to another thread
since the first is finished consuming the results and the entire result
set is in the StoreQueryResult. (Looking at the code, that looks safe
since I'm just calling vector::at())
btw. As your pages says, using a connection on multiple threads is
dangerous. We had a nasty bug where a Python script running in our app
passed a MySQL connection to different threads and would cause random
From: Warren Young [mailto:mysqlpp@stripped]
Sent: Thursday, March 05, 2009 10:52 AM
To: MySQL++ Mailing List
Subject: Re: Confirmation about thread un-safety/safety
Jim Wallace wrote:
> I know you can't use the same connection object on different threads.
I don't think that's true, as stated. What you can't do is use a single
connection object for two different queries at once. This issue really
has nothing to do with threads:
Threads just make it harder to avoid running into this limitation.
> It looks like I can 't do query.store() on one thread and
> query.store_next() on another since it calls
Did you try it and find that it fails, or are you just avoiding it
because you think it won't work? If the latter, try it anyway.
Obviously due to the simultaneous query issue, you do have to avoid
making another query on that connection until the second thread has
finished consuming the results. If you were hoping to avoid this,
perhaps so you could have one thread processing results while another
starts new queries, then you do indeed need at least two Connections.
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus