Anyone can join in live, and the meeting will also be recorded and posted eventually at their Youtube Channel.

Here's the description for my talk, which is also offered on my site's presentations page:

[....Continue Reading....]

Note: This blog post is from 2018. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

[....Continue Reading....]

Note: This blog post is from 2016. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

For instance, what's the version of Solr? (It's considerably upgraded over what was in CF11 and 10). What about Java, Tomcat, Hibernate, ehCache, 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. :-)

[....Continue Reading....]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

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.

[....Continue Reading....]

Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

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.

[....Continue Reading....]

Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Several Performance Advantages, and Failover As Well

[....Continue Reading....]

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

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).

[....Continue Reading....]

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

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.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

First, notice that there is a site at the DataDirect site (from whom Adobe purchases the JDBC drivers):

http://media.datadirect.com/download/docs/jdbc/alljdbc/reference/spy.html

It discusses some additional attributes. And still more useful info is offered at another page on their site:

http://media.datadirect.com/download/docs/jdbc/alljdbc/reference/diagnostics2.html

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.