List:MySQL++« Previous MessageNext Message »
From:Paul Martin Date:November 8 2007 10:33pm
Subject:Re: Issues with multi-queries
View as plain text  
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 

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 

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.


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 =;

            /*          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;




Code #2:

// Set up query with multiple queries.

      Query query = con.query();


      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() <<

      // Execute statement and display all result sets.


      cout << "success\n";



----- 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:
> 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,
>> --
>> MySQL++ Mailing List
>> For list archives:
>> To unsubscribe:

Issues with multi-queriesPaul Martin7 Nov
  • Re: Issues with multi-queriesWarren Young7 Nov
  • Re: Issues with multi-queriesPaul Martin7 Nov
    • Re: Issues with multi-queriesWarren Young7 Nov
  • Re: Issues with multi-queriesPaul Martin8 Nov
    • Re: Issues with multi-queriesWarren Young8 Nov
      • Re: Issues with multi-queriesMaarten Schrijvers8 Nov
  • Re: Issues with multi-queriesPaul Martin8 Nov
    • Re: Issues with multi-queriesWarren Young10 Nov
  • Re: Issues with multi-queriesPaul Martin10 Nov
    • Re: Issues with multi-queriesWarren Young10 Nov
  • RE: Issues with multi-queriesIan Daysh12 Nov
    • Re: Issues with multi-queriesWarren Young13 Nov