OK, to keep things as simple as possible I have modified my example, and am
getting the same results. I went back to the original 2.3.2 release
multiquery.cpp file and detailed the 6 changes I made below, along with the
relevant code snippets.
The results:
- connection dies EVERY TIME on the second go-around of the loop.
- with 'Sleep(200)' not commented out the connection dies ALWAYS after 1-40
iterations
I think this eliminates the original changes I made as the culprit and
points out the problem. Whether its the connector or database I don't know.
Again I think maybe the database is not ready for the next query as maybe a
thread is still active and the function returns too soon. I also think its
not noticed with the screen output turned off as this slows execution down
just enough.
Any ideas that I can try I welcome... I'm just trying to figure out why its
happening.
PS Thanks for the reply Maarten but I don't think that's the problem since I
am reusing the same connection and it dies long before 100.
Paul
CHANGES TO multiquery.cpp:
1. Comment out 4 lines starting with 'print_result' in the
'print_multiple_results' function (to kill screen printing)
2. Put 'for(;;){' below 'Query query = con.query();' in main (start of
forever loop)
3. Commented out 'cout << "Multi-query: '... line after the query is built
(again to kill screen printing)
4. Added 'cout << "success\n";' after the 'print_multiple_results(query);'
line (to indicate a successful query)
5. Added '//Sleep(200);' on the next line (for testing)
6. Put '}' on next line (end of forever loop)
Code #1:
static void
print_multiple_results(Query& query)
{
try {
// Execute query and print all result sets
Result res = query.store();
/* print_result(res, 0);
for (int i = 1; query.more_results(); ++i) {
res = query.store_next();
print_result(res, i);
}*/
}
catch (Exception& err) {
// Something bad happened....
cerr << "Multi-query failure: " << err.what() << endl;
exit(1);
}
}
Code #2:
// Set up query with multiple queries.
Query query = con.query();
for(;;){
query << "DROP TABLE IF EXISTS test_table;" << endl <<
"CREATE TABLE test_table(id INT);" << endl <<
"INSERT INTO test_table VALUES(10);" << endl <<
"UPDATE test_table SET id=20 WHERE id=10;" << endl <<
"SELECT * FROM test_table;" << endl <<
"DROP TABLE test_table" << endl;
//cout << "Multi-query: " << endl << query.preview() <<
endl;
// Execute statement and display all result sets.
print_multiple_results(query);
cout << "success\n";
//Sleep(200);}
}
----- Original Message -----
From: "Maarten Schrijvers" <maarten.schrijvers@stripped>
To: <plusplus@stripped>
Sent: Thursday, November 08, 2007 6:22 AM
Subject: Re: Issues with multi-queries
> This might be of interest for your problem. I noticed MySQL has a system
> variable for max_connections:
> http://dev.mysql.com/doc/refman/5.0/en/too-many-connections.html
>
> 2007/11/8, Warren Young <mysqlpp@stripped>:
>>
>> Paul Martin wrote:
>> > My point is not to debug my own code,
>>
>> Are you certain that it isn't bugs in your code that are causing the
>> problem, then?
>>
>> This is the first message I remember seeing on this list in the 2+ years
>> we've supported multiqueries that suggests that they just don't work.
>> Either you're the first to really use them, or your code has a bug.
>>
>> > The endl's are used because the original multiquery example used them.
>>
>> Ah. We had them in there only to make the preview() calls prettier.
>> I've removed them.
>>
>> > I've just modified a simple example to show it break.
>>
>> You haven't "shown" anything. You've just stated that "this is the
>> case" with no proof. What you posted doesn't compile and run, and
>> neither I nor probably anyone else is going to take the time to change
>> it until it does break, if only because you can't prove that something
>> _doesn't_ happen. It's up to you to prove that it _does_.
>>
>> You have to meet us more than halfway on this. We're unpaid volunteers.
>>
>> > I suppose I could use the sample db but that might not behave the same.
>>
>> I addressed this in my previous email: if it doesn't behave the same,
>> that tells you something interesting and useful. It's a legitimate
>> troubleshooting step, totally separate from the matter of making it
>> convenient for people to test things for you on their machines.
>>
>> > I have a feeling the engine isn't ready for another call for a short
>> > time,
>>
>> Some of the biggest sites on the net run on MySQL. These sites see
>> normal loads of thousands of queries per second, and I assure you, they
>> don't have magic delays between every query. If that were necessary,
>> MySQL wouldn't have achieved its present popularity, and even if it had,
>> MySQL++ would either do this internally for you or tell you to do it in
>> the user manual.
>>
>> > It looks like there may be a memory leak issue as well,
>>
>> http://tangentsoft.net/mysql++/#memleak
>>
>> --
>> MySQL++ Mailing List
>> For list archives: http://lists.mysql.com/plusplus
>> To unsubscribe:
>> http://lists.mysql.com/plusplus?unsub=1
>>
>>
>
