List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:October 16 2008 10:38pm
Subject:Re: problem with query (execute) timeout option
View as plain text  
Seth Linden wrote:
> code compiles without error but the opt_write_timeout option doesn't
> change a thing.

All MySQL++ is doing here is passing the option on to the MySQL C API, 
with trivial translations in form.  In this case, it translates to:

	int arg = 1;	// passed option argument value
	return !mysql_options(mysql_, MYSQL_OPT_WRITE_TIMEOUT, &arg);

New MySQL options have been added all through its history.  Since 
MySQL++ is acting as a wrapper for a great range of MySQL versions, it 
just presents all of them to you.  At MySQL++ build time, calls into the 
C API get ifdef'd out if the version of the C API you're building it 
against doesn't support the feature in question.  In the case of the 
read and write timeout options, these were introduced in MySQL 4.1.1. 
If you built MySQL++ against headers from MySQL 4.1.0 or older, the 
set_option() calls will literally do nothing.

Additionally, in the MySQL docs we find: "This option works only for 
TCP/IP connections, and only for Windows prior to MySQL 5.0.25."

If the problem is something else, then my guess is that the options are 
doing exactly what they're supposed to, but they don't control what you 
think they ought to.  For instance, it's not clear to me that the read 
or write timeouts will curtail a long-running query.  I would expect 
them to only control socket I/O, which can be nearly instant, but in 
between writing the query string and receiving the reply, the server 
could take a long time to process the query.  I would expect to see a 
separate query timeout feature to control this, but I can't find one.  I 
guess it either doesn't exist, or it's lumped in with the read timeout.

> Was this fixed in a later version?

There have been bugs in the option setting mechanism, and the mechanism 
was totally revamped in v3, but I don't believe this particular option 
is affected.

Still, there are plenty of other reasons to upgrade to v3.

> Also, what is the best way (within the API) to find out if the table is
> locked?

If there is a way, it would be with a MySQL-specific query, which would 
be on-topic on the main MySQL list.
problem with query (execute) timeout optionSeth Linden16 Oct
  • Re: problem with query (execute) timeout optionSeth Linden17 Oct
    • Re: problem with query (execute) timeout optionWarren Young17 Oct
  • Re: problem with query (execute) timeout optionWarren Young17 Oct