For instance, what's the version of Solr? (It's considerably upgraded over what was in CF11 and 10). What about Java, Tomcat, Hibernate, Hibernate, Quartz, jQuery, and so on?
In this post, I offer a rundown of what seem the most significant libraries and their versions, as deployed in the first release of ColdFusion (2016 Release). I also explain how I found these version numbers, which isn't always obvious, in case that may help others. But I also offer some commentary on why this is an important issue to some, and I offer some counterpoints to the demands some have that every library should always be the absolute latest version (and why that's just not practicable).
If you just want the version numbers without the "waffle", look for the bulleted list of them below. :-)
Summary: There is a reasonable explanation and a rather simple solution: update the MySQL driver that CF is using to at least version 5.1.22 of the driver, the first to support MySQL 5.6, because the one built into CF 10 (driver version 5.1.17) not only does not. More important, that older driver uses something that causes the failure above in 5.6.
That explanation of the "solution" may be enough for some to take the ball and run with it (and if not, I will offer more details on how to do that), though it should be noted that updating the driver is not formally supported, nor is MySQL 5.6 technically supported at all in CF10 (or 9). But for those who will press on knowing that risk, you now know what you need to do.
But as often, there's much more to this than meets the eye, so I hope you will follow along to learn more. I have broken this into two parts:
- the problem (with what I hope is helpful explanation of what the real root of the problem is),
- who's to blame (not Adobe, I will argue)
- and the solution (with some caveats that even experienced folks, or those who don't care about "the problem", should still read.
And again, while I discuss this in the context of CF10, where I've seen the problem happen, it could apply also to CF9 (and it seems reasonable that it would), so all the information still applies, it would seem.
Did you know there is now a setting in the DSN page of the CF Admin (for most of the Adobe-provided DB drivers) which allows you to set a maximum timeout for queries against that DSN?
It's a new feature enabled for the DataDirect drivers, as updated in CF 9. (You will not see it if you use an "other" datasource type, such as when using a downloaded JDBC driver that you implement on CF.)
The caveat? This timeout is ONLY settable there in the DSN definition, not in CFQUERY (or CFSTOREDPROC) itself, which is a shame. The existing TIMEOUT attribute for those (CF10 added it for CFSTOREDPROC) is not the same and generally does not work. Still, the value of this even at the DSN level is too important to ignore for some challenges. More on that (and some other thoughts) in a moment.
Several Performance Advantages, and Failover As Well
Well, there are several ways you can watch them, as this entry will discuss, and some may be better suited to the job than others. It can be very interesting to discover what's going on, especially if you're having any suspected performance problems which you think may be related to ORM processing (or just if you wonder what all it does for you).
As for spying on the SQL, of course ORM support is just a different way that the CFML engine (through the ORM framework) sends SQL to a database via a regular DSN, just like any other request, so there's nothing really "tricky" about this. It's just about realizing that while you don't write the SQL yourself, it's still generated by the CFML engine/ORM framework, and you may not realize/consider the available tools which can spy on it, just like any other DB processing from within CF. Indeed, some people may not even realize how many options exist to spy on JDBC interactions from their CFML engine to the database engine.
The good news is that there are several approaches, some included in CF (some depending on the edition), and some available separately which would work in any edition of CF or the other CFML engines (Open BlueDragon, Railo, etc.), and with any of the ORM frameworks. And again, some may be better than others for certain challenges.
(FWIW, besides the aforementioned Transfer and Reactor, there are still other ORM solutions for CFML, which I mention in my CF411 list as CFML ORM Frameworks. Indeed, note that you can run Hibernate on CF prior to CF9, if you want to. This is a recovery of a blog entry that no longer exists, recovered via archive.org.)
Built-in ORM Logging Option
First, note that for those using CF9+ ORM, there is indeed a built-in option in the CF ORM setup where one can enable logging, settable in the application.cfc: see the this.ormsettings option and its available key/value pair, logSQL="true".
There are several resources where you can learn more on that (and a related log4j property file approach to logging this). Besides the CF9 docs page on the ORM settings, there is also a blog entry by Adobe engineer Rupesh Kumar.
The default is to log this information to the console, but you can manipulate those log4j settings to tell it to use a file (see the links above). Even so, this will result in quite a lot of data being logged, which you will then need to connect back to your specific requests. The following approaches may be preferable.
Using FusionReactor or SeeFusion
Users of any CF edition (6+) or any CFML engine (Railo, OpenBD, or BD 7+) can use tools like SeeFusion and FusionReactor, which have always had the ability to monitor database interactions by "wrapping" the datasource to be monitored. FusionReactor engineer John Hawksley has posted a recent article specifically on monitoring CF9's ORM interaction, in the FR Devnet site, Using FusionReactor's JDBC Driver Wrapper With ColdFusion 9 ORM. Its concepts would apply to any ORM, of course.
Similarly, I've written generically about FusionReactor's database monitoring feature in What is the FusionReactor datasource monitoring feature? Why would I use it? Powerful stuff. As I point out in that article, the concepts discussed apply as well to SeeFusion's ability to monitor queries by wrapping datasources.
That said, it's worth noting that FusionReactor does have a couple of advantages, in that it provides for the display of all queries for a given request (while viewing the details of that request), whereas SeeFusion only lets you see the slowest query in a given request. FusionReactor also provides a separately available display of all the slowest queries (across all requests). It also logs every query (connecting it to a given request as well), while SeeFusion (Enterprise, at least) can also log the slowest queries to a database.
And note that both of these track any requests coming out of CF, not just those associated with a given request. So if there is ORM SQL that is associated with the startup of CF, that's tracked too. (And for those aware of issues with CF's Client Variables, such DB activity is also tracked, even that done by the hourly purge, which takes place on a background, non-jrpp thread.)
CF Enterprise Server Monitor
Those running CF 8 or 9 (Enterprise only) will find that its available Server Monitor does offer built-in monitoring of the SQL executed against CF datasources, at least, as long as you enable "Start Profiling" (which also enables other features, and overhead, as well). In this way, the Enterprise Server Monitor can monitor database interactivity, including ORM interactions.
Unlike FusionReactor (and like SeeFusion), it focuses only on showing queries that exceed certain limits, and at that it shows them only in a "Slowest Queries" interface, tracking the slowest queries among all requests. The CF Enterprise Server Monitor also has no logging ability at all.
Being able to see every single DB interaction for a given request (or across all requests) may be all the more interesting for discovering/observing what's happening with ORM interactivity.
Another alternative CF feature
Still another little-known feature for spying on JDBC interactions in CF is by way of the JDBC "spy" feature, which does in fact allow logging of all JDBC interactions mde from within CF. This feature was first enabled by way of the DataDirect 3.5 driver update which was made available (as an optional upgrade for 6 and 7) in the CF 7.02 timeframe. I wrote about the Spy feature back back in Aug 2006.
Since then, CF 8 (and now 9) offer it instead as a new "log activity" option in the "advanced settings" for a datasource definition in the CF Admin (which is disabled by default). I pointed this out in another entry from 2007 as one of many easily missed changes for the CF 8 Admin.
This "log activity" output is not as easy to interpret as FusionReactor's logs, and can indeed be voluminous (moreso than FR's), so be careful. Anyway, it's one of the several ways you can monitor JDBC interactions between CFML and your DB engine. Again, any of these may be useful for monitoring any of your CFML/database interactions.
Generic DB Monitoring tools
Indeed, it's worth noting finally that while the focus here has been watching the DB interaction from CF (and the ORM framework) to the database (by watching the JDBC traffic going out of CF and returning), you could just as well watch the DB interactivity from the DB's perspective instead (watching it coming and and being returned).
There are many tools that can monitor database processing, available for each of the major databases (free and commercial). I list several such tools in one of my CF411 section, Database/SQL Monitoring Tools.
Hope all that's helpful, whether you use ORM or not.
This news has been shared in various blog entries over the past couple of years. I'd like to reprise them here for your edification. (Note that while they may show how to look at some particular driver, like SQL Server, you can--and would need--to change what they show to look at whichever driver you are interested in. More on that below.):
- Pete Freitag showed some CFML code that gives you the answer on screen
- Brandon Purcell showed a CFML approach that writes its output instead to the CF log files instead (see below for more)
- Steven Erat did a post that is a take-off on Brandon's approach. He too writes his result to the logs, but he shows code naming several different driver class names and showing their versions (at least as they were known then, in 2005). That list of classnames may still be useful in later years. See below. [Indeed, as an update, in 2008, Dan Switzer did another take on that hard-coded listing of driver names, and comments in 2013 showed it working for CF10 then.]
- Finally, Sarge showed how to get the info via the command line (again, see below for more on this, and see also my last comment in the comments section below the post, for a related tip on running that java command)
So a couple more thoughts on all this.
And about the last two options above
First, in the case of the second two options above, note two things:
- Those last two links are versions of each page as recovered using the good 'ol internet archive/wayback machine. For more on the value of this wonderful tool, see my post on that.
- Note that those last two links make reference to files or folders under C:\CFusionMX\ or C:\CFusionMX7\ folders, reflecting the time they were written. For those on CF10 and above, you would look now instead under [yourcf]\cfusion\, or if using instances, [yourcf]\[yourinstance]\.
Finding the version of the driver YOU are using
Second, I said above that you would need to use the name of the driver you really mean to look at, which may be different than what their example show. For instance, Pete's code shows looking at the SQL Server driver, macromedia.jdbc.sqlserver.SQLServerDriver. So what if you're using the Adobe-provided Oracle driver? Or any other?
Well, some good news if you use an "other" driver type (where you choose that in the CF Admin DSN page), then you must provide the driver classname yourself. That would be the name to use.
But what if you one of the several other kinds of drivers listed on that page? CF doesn't show you the classnames it uses for that. (And I could not find it in several places I looked. More below.)
But again see Steven Erat's code above that listed several of the class names known at the time (and which still seem fairly accurate more recently).
And while there are still other places that clever readers may want to point out that may hold them, I could not find them in these places:
- The DSN classname is not listed in the CF Admin page where you add/edit a DSN
- The DSN classname is not not listed in the CF Admin "settings summary" page, even though that does offer useful additional info, like the underlying jdbc URL that CF builds, when using its built-in DB drivers
- They classname is also not listed in the XML within the neo-datasources.xml or neo-drivers.xml files, if you know about them. There ARE classnames there, but you will see that if you look, for instance, at the SQLServer one, it does show a classname (in the "class" xml element). But it's just macromedia.jdbc.MacromediaDriver, not the macromedia.jdbc.sqlserver.SQLServerDriver used in the examples above.
- They're also not listed in the "system information" page in the CF admin--the "i" icon in the top right--which shows the "CF Server Java Class Path". That does not list the class names for the Adobe-provided DB drivers, because they are instead all embedded in one jar, called macromedia_drivers.jar. Really determined folks may know you can unzip that and dig around and determine class names and paths, but I won't elaborate that here.
So it seems that for the built-in CF-provided drivers, you're best off just using the variations offered in those examples above (especially Steven's).
Hope all that help others as much as they have me over the years.
First, notice that there is a site at the DataDirect site (from whom Adobe purchases the JDBC drivers):
It discusses some additional attributes. And still more useful info is offered at another page on their site:
This actually shows what the log of info would look like, if you want to decide first if its info is worth the bother setting up.
This other page also talks about ways to turn the spy logging on and off at runtime, using Java method calls. Perhaps someone with more familiarity with the underlying Java classes for these drivers can translate the code there into something we can use in CFML. (It's late, and I don't have the energy.)
As such, be aware that the spy feature could generate a lot of data, so you may want to consider creating two datasource for each DB you may want to monitor. Either rename them to enable whichever you want to be in effect, or change if your code lets you specify a DSN via a variable, you can change the value to the "spying" version when you need it.
I did test and determined that also you can just add/remove the connection string from the end of the JDBC URL (see the technote for more), and immediately the logging stopped against the datasource. As a trick, I stuck the connectionstring value into the "description" field of the datasource definition, to keep it readily accessible if I wanted to add it back. (See my previous entry for a warning about putting it into the ConnectionString field instead.)
Finally, I should clarify that this Spy feature is not to be confused with the much older (and more powerful) p6Spy project, which has gone from open source to commercial to kind of stagnant. It still has great use, and in fact has a useful related SQL Profiler that's worth looking at. Still more at http://www.p6spy.com/, and maybe I'll write more about it later.
I have a few questions/observations for others who have run it or may consider it, and they apply to 7.02 and 6.1 users, such as whether you need to apply it manually and about the various new features it adds, like integrated NT authentication for SQL Server, and a new JDBC Spy feature for any DBMS? More on them in a moment.
Do you need to update this for 7.02? 6.1?
First, do you need to apply the update manually if you're running 7.02, or even one of the later cumulative hotfixes (CHFs)? It doesn't say specifically. While it may seem we should presume it was included in 7.02, I think we should not. Some features it adds (below) are not in the C:\CFusionMX7\lib\macromedia_drivers.jar (whose date is also from 2004, at least on my 7.02 install.)
(UPDATE: In fact, it appears that the updated drivers were NOT in fact included in 7.02, or any CHF. First, as mentioned in the comments below a discussion on the Adobe Forums confirmed that these drivers were NOT included in 7.02. Also, note that CHF 1 for 7.02 lists the link for the driver updates as something you need to do yourself, under "additional information". There's also no mention of the JDBC drivers in the technotes for 7.02 CHF's 2 or 3, so it seems safe to conclude that 7.02 users do need to apply the update individually to get the updated JDBC drivers.
But better still, if you have 7.02 installed and wonder what version you have, you can find out for yourself. Check out this later entry of mine which helps you determine what version of the DB drivers you are indeed now running.)
As for 6.1, it's not clear but do we need to apply it if we have the latest 6.1 updater (6,1,0,83762 )? Again that build's macromedia_drivers.jar also lacks some of the files added by this updater, so I would assume so. I applied the update to my CFMX 6.1 updater release including also the important updating of the Sequelink ODBC Server as indicated in the technote. Don't miss that, if you're running on 6.1 (not needed on 7). After restarting, things are working.
Warning for those with 6.1 and 5 installed
I should note that I did find that my CF5 server (also running on this same dev box) suddenly, and for the first time ever since this box was created a few months ago, started raging with a persistent 55% cpu utilization for ntconsolejava.exe. I certainly would have assumed that the problem was in my CFMX 6.1 services, but by process of elimination it was the stopping of "ColdFusion Management Repository Server" (from CF5) that did the trick. That runs a JRun instance in the CF5 server.
I can't see how this would be connected, but I point it out in case it happens to others. I don't know what to do about it. I may just stop my CF5 server until I ever need it. I suppose I could also just set the management service to manual. I don't recall what the mgt service did in CF5. A quick review of the docs shows it had to do with archiving and admin reporting.
New Features in the Update Driver
But perhaps more important, as for the features it adds, did anyone notice the "sql server nt authentication" it enables? It seems that would solve a useful problem, but I could not get it to work. I followed all the steps including extracting the DLL (it's in the zip) and creating an "other" datasource type with the provided "authenticationmethod" in the JDBC URL. Has it worked for anyone?
Note also the interesting new spy feature, which can provide some useful diagnostics (think SQL Profiler, but for any DB and all the info tracked in a log file on the CF server). I was able to get it working successfully with a SQL Server database (using the "other datasource type" as explained in the technote), but when I tried to add it to an odbc dsn against an Access DB, using the connection string approach listed, nothing happened (no spy log created, until I used the "other datasource approach).
Note as well that the updates offer various fixes for SQL Server, Oracle, and Informix. It's also an update that pure JRun 4 users can/should run. I will point out that one blogger has found a change in behavior regarding multiple statements on a single SQL line: http://www.feed-squirrel.com/blog/index.cfm/2006/6/8/CREATE-TABLE-from-CF-7.
See the technote (linked at the top here) to learn more. I've also opened a question in the Adobe forums with this same info: http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=143&threadid=1180864&enterthread=y, as I can't assume as many people read my blog as will read that.
I'll be curious to hear (here or there) what others have experienced and what they think of these new features.
I should warn that the technote indicates a couple of times that you should not try to put these new connection string values into the "connection string" field of a DSN, instead creating an "other" datasource type and providing them on the JDBC URL for that DSN. When I made the mistake, I found that I could not query any ODBC datasources nor could I even start the CFMX Admin or get debugging on any page. All complained that the "DataSource service is not available.". I found no neo-query.bak to recover from, so was quite stuck. A careful analysis of the new-query file found that inappropriate CRLF character codes had made their way into the file (As 0a and 0d values that made for bad xml). I removed them (not trivial to do correctly) to get things back in order, so FOREWARNED IS FOREARMED.