Although a debugger can be used to debug your application, you may find it beneficial to turn on the debug traces of the connector. Some problems happen randomly which makes them difficult to debug using a debugger. In such cases debug traces and protocol files are more useful because they allow you to trace the activities of all instances of your program.
DTrace is a very powerful technology to trace any application without having to develop an extra trace module for your application. Unfortunately, DTrace is currently only available on OpenSolaris, Solaris, MacOS 10.5 and FreeBSD.
The MySQL Connector/C++ can write two trace files:
Trace file generated by the MySQL Client Library
Trace file generated internally by MySQL Connector/C++
The first trace file can be generated by the underlying MySQL
Client Library (libmysql). To enable this trace the connector will
call the C-API function
internally. Only debug versions of the MySQL Client Library are
capable of writing a trace file. Therefore you need to compile
MySQL Connector/C++ against a debug version of the library, if you want utilize
this trace. The trace shows the internal function calls and the
addresses of internal objects as you can see below:
>mysql_stmt_init | >_mymalloc | | enter: Size: 816 | | exit: ptr: 0x68e7b8 | <_mymalloc | >init_alloc_root | | enter: root: 0x68e7b8 | | >_mymalloc | | | enter: Size: 2064 | | | exit: ptr: 0x68eb28 [...]
The second trace is the MySQL Connector/C++ internal trace. It is available
with debug and nondebug builds of the connector as long as you
have enabled the tracing module at compile time using
cmake -DMYSQLCPPCONN_TRACE_ENABLE:BOOL=1. By
default, the tracing functionality is not available and calls to
trace functions are removed by the preprocessor.
Compiling the connector with tracing functionality enabled will cause two additional tracing function calls per each connector function call. You will need to run your own benchmark to find out how much this will impact the performance of your application.
A simple test using a loop running 30,000 INSERT SQL statements showed no significant real-time impact. The two variants of this application using a trace enabled and trace disabled version of the connector performed equally well. The run time measured in real-time was not significantly impacted as long as writing a debug trace was not enabled. However, there will be a difference in the time spent in the application. When writing a debug trace the IO subsystem may become a bottleneck.
In summary, use connector builds with tracing enabled carefully. Trace enabled versions may cause higher CPU usage even if the overall run time of your application is not impacted significantly.
| INF: Tracing enabled <MySQL_Connection::setClientOption >MySQL_Prepared_Statement::setInt | INF: this=0x69a2e0 | >MySQL_Prepared_Statement::checkClosed | <MySQL_Prepared_Statement::checkClosed | <MySQL_Prepared_Statement::setInt [...]
The example from
demonstrates how to activate the debug traces in your program.
Currently they can only be activated through API calls. The traces
are controlled on a per-connection basis. You can use the
setClientOptions() method of a connection
object to activate and deactivate the generation of a trace. The
MySQL Client Library trace is always written into a file, whereas
the connector's protocol messages are printed to standard out.
sql::Driver *driver; int on_off = 1; /* Using the Driver to create a connection */ driver = get_driver_instance(); std::auto_ptr< sql::Connection > con(driver->connect(host, user, pass)); /* Activate debug trace of the MySQL Client Library (C-API) Only available with a debug build of the MySQL Client Library! */ con->setClientOption("libmysql_debug", "d:t:O,client.trace"); /* Tracing is available if you have compiled the driver using cmake -DMYSQLCPPCONN_TRACE_ENABLE:BOOL=1 */ con->setClientOption("client_trace", &on_off);