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.
