For years, Connector/Net has been a key part of any MySQL & .NET developer’s toolbox. Tracing is also a key part of a developer’s life and Connector/Net has always output trace messages.
This first post is a review of .NET tracing systems and how we changed our trace output. The second post will cover how developers can use the new tracing format to develop new applications.
Tracing in .NET 1.x
.NET shipped with a very simple tracing system. You have a static class named Trace that has static methods such as Write and WriteLine. An application can use code like the following to output a message to the trace log.
Now that we have output our message, how do we direct it somewhere? You do that with listeners. There are a few standard listeners included in the framework (ConsoleTraceListener, XmlTraceListener, EventLogTraceListener) but you are free to create your own. You can attach a listener at runtime or via an application configuration file. There’s no need to show you how that is done. You can easily find it on the web. What we really want to talk about are changes in .NET 2 tracing and how Connector/Net makes use of it.
Tracing in .NET 2.x
Developers usually want to just trace a particular part of an application. They may just want to get the network tracing or maybe just the file I/O. To accommodate this, Microsoft created a new class named TraceSource. You can really think of it as just a Trace class with a name. Now when you add listeners via the config file you have to add them to a source with a particular name. Here’s what it might look like.
<source name="TraceTest" switchName="SourceSwitch"
<add name="console" />
<remove name ="Default" />
<!-- You can set the level at which tracing is to occur -->
<add name="SourceSwitch" value="Warning" />
<!-- You can turn tracing off -->
<!--add name="SourceSwitch" value="Off" -->
You can also specify a switch level, a filter level, and trace options (like should the output include process id, thread id, timestamp, etc).
Starting with Connector/Net 6.2, we have started using TraceSource to output our trace data. Our source is named, cleverly enough, mysql.
Using the mysql trace source
Using our new tracing is very simple. Just use a configuration block similar to what I have above except use “mysql” as the name of the source instead of “TraceTest”. One question you may have, though, is how to add listeners to our source at runtime. You do that with the new MySqlTrace class. Here’s how.
Difference is in the details
We’ve also increased the level of detail included in our trace messages. Each trace message includes a counter value that attaches it to other trace messages belong to the same connection. We did this to enable the development of applications such as a powerful log viewer that will also serve as a visual trace listener. With this app, a developer would be able to query the log output for various scenarios. Examples would be “show me all queries where all the rows were not read
So where to from here?
There’s much more to say about our new trace output and, in my next post, I’ll go into the exact format of the data, and we (and you) can use that data to create new and exciting trace listeners.