Warren Young wrote:
> Tom Moers wrote:
>>
>> Did you even look at the diagrammed scenario?
>
> Yes, and it's what I described in my very first reply to you. We're not
> disagreeing on what *can* happen. We're disagreeing on what is *likely*
> to happen.
>
>> I'm contending that the diagrammed scenario is possible with
>> your example as it is now; not because of thread creation times,
>> but because of the 6 'grab, use and release connection' iterations
>> that each of your 14 threads make: it is possible that a connection
>> is created and released in one thread and then grabbed by a
>> different thread before the creator thread reuses it.
>
> This is where you're getting confused. It doesn't matter if thread 2
> uses a connection created by thread 1 *if* thread 2 has registered
> itself with the C API library. It does that either implicitly by
> creating at least one connection of its own, or by explicitly by calling
> mysql_thread_start(). Once that has been done, it never has to be done
> again as long as the thread runs, no matter which connections it uses.
>
Thanks, this is what I needed to know. I misunderstood
the documentation:
"If your program’s connection-management strategy
allows a thread to use a Connection object that another
thread created, you must call Connection::thread_start()
from these threads before they do anything with MySQL++."
I assumed that because thread_start is a member of
Connection, it somehow linked the connection to the
calling thread. And that you consequently had to call
connection->thread_start whenever you start using the
connection in a thread that did not create it.
I know it's maybe too late, but may I suggest moving
these thread_x to the mysqlpp namespace ?
> <SNIP>
> It may help you to clear this up by reading this section in the C API :
>
> http://dev.mysql.com/doc/refman/5.0/en/threaded-clients.html
>
Yes, thanks. This helped.
Best regards,
Tom
