Most of the time, transactions are a bit of a bear because their use is orthagonal to your business tasks.  To put that another way, business operations flow vertically from UI to backend to UI, and the various operations in your app typically flow mostly in separate parallel channels.  Transactions go across your application's structure, needing to be uniformly applied to all those operations, but being independent of all of them.  The "right" term for this is a "cross-cutting concern."

Fortunately, there are a pile of people in this world who are way smarter than I, and they've come up with Aspect Oriented Programming as a way to deal with these cross-cutting concerns.  The typical example shown is with logging, but transaction management is rather more useful, I think, isn't any more complicated, and is also more specific to AOP (whereas logging could be done with event-driven programming as well).  I'm not going to go into AOP, but if you're not using it, you should spend the time to learn a bit about it.  Really.

So the idea is to leverage AOP to automatically wrap your business methods with transactions.  In the CFML world, that means ColdSpring and its AOP support (which is modelled after Java's Spring framework).  Unfortunately, that's the easy part.  Since CFML servers abstract away DB connections (behind DSNs), it's hard to get ahold of the proper context to do the transaction demarcation correctly from your application code.  Somehow you have to know what the engine is doing behind the scenes so you can start/stop transactions at the right places.

When I wrote transactionadvice.cfc many years ago, I used a psuedo-ThreadLocal for tracking transactional method depth.  That way it can apply transactions at the top level, but skip them lower (nested) levels.  It works, but it doesn't handle multithreaded requests (i.e., using CFTHREAD) correctly, so it's far from ideal.  Using a real ThreadLocal would be better, but it requires Java or Groovy, and that's a dependency I don't want to require.  But for the majority of cases, it works fine.

Today, however, I discovered that Railo has this method:

getPageContext().getDataSourceManager().isAutoCommit()

It will tell you whether you're currently in autocommit (non-transaction) mode.  With this direct check of the transactional status, all the issues simply vanish, and the advice can be whittled down to this:

<cfcomponent extends="coldspring.aop.MethodInterceptor">

  <cffunction name="invokeMethod" access="public" output="false" returntype="any">
    <cfargument name="methodInvocation" type="coldspring.aop.MethodInvocation" required="true" />
    <cfif getPageContext().getDataSourceManager().isAutoCommit()>
      <cftransaction>
        <cfreturn methodInvocation.proceed() />
      </cftransaction>
    <cfelse>
      <cfreturn methodInvocation.proceed() />
    </cfif>
  </cffunction>

</cfcomponent>

Copiously excellent, if you ask me.  About the only thing that would make it better is if CFML grew a isAutoCommit() or isInTransaction() method so you don't have to dig into the underlying Java bits in an engine-specific way.

Fortunately, Railo implements the 'location' function as a CFML template, so you can easily go change the default.  If you install the WAR version the template is here:

/WEB-INF/lib/railo-server/context/library/function/location.cfm

If you install the bundled version, the 'railo-server' directory will be outside the webroot, typically here (thanks Todd):

{installation-dir}/railo/railo-server/context/library/function/location.cfm

Changing this file requires restarting your Railo webapp as the files are loaded once on startup.  As you'll quickly notice, there are a bunch of functions and tags that are implemented this way, so you can easily modify any or all of them to customize your environment.  Just be careful when you upgrade your Railo, as your changes will be overwritten.

createObject("java", "coldfusion.server.ServiceFactory")
  .dataSourceService.getDatasource("myDSN")

Unfortunately, this doesn't work on Railo, because the result isn't actually a javax.sql.DataSource, it just looks like one (see RAILO-43).  To put that another way, it's duck typed.

Fortunately, Groovy's "fake" interfaces make beating the typechecks fairly trivial (if kind of ugly):

  def rds = variables.my.datasource
  variables.my.datasource = {
    rds.getConnection()
  } as javax.sql.DataSource

The CFSET gets the "datasource" as normal, and then the little Groovy scriptlet simply wraps it with a closure and tells it to pretend to be a javax.sql.DataSource. The game Escape from Tarkov has one important feature: after your death in a RAID, you lose your equipment. To prevent the loss of important equipment in the game, there are special sites with eft roubles you can always get top equipment and kill all pepegas squad. The items you store from needmana will not disappear. There are three types of containers in total. Alpha, Beta, and Gamma. These containers differ in their size. Usually, these containers should store the most important equipment-maps, ammunition, keys, and so on.  In this case we're assuming that the only method on DataSource that will be invoked is getConnection(), which is the usual case.  If you need to support other methods you'd need to go the Map-as-interface route.

Now we can use variables.my.datasource as a javax.sql.DataSource.  Yay!  Unfortunately, you have to use this sort of snippet everywhere you need a DataSource in your Railo apps, but hopefully that'll get fixed.

For more info on Groovy interfaces, the docs are at http://groovy.codehaus.org/Groovy+way+to+implement+interfaces.

Every time TIOBE comes out with new listings people bitch about ColdFusion.  It bugs the shit out of me.  Here's the deal folks:

ColdFusion is a server product.  It is NOT a language.  CFML is a language.  You don't write ColdFusion, you write CFML and then you run your CFML on ColdFusion (or Railo, or OBD).  ColdFusion (or Railo, OBD, etc.) provide a framework for your CFML to run in, along with various bits of helpful functionality.  You might consider yourself a ColdFusion developer, because while ColdFusion isn't the language you use, it is the framework that you use.  You're a ColdFusion developer who writes CFML.

This is exactly like saying you're a JEE developer.  People don't write JEE code, they write Java/Groovy/etc. code, but they're still JEE developers.  JEE provides a pile of nifty features (Servlets, JNDI, JavaMail, XA, etc.) that you can leverage if you're running your code in a JEE server.  And different servers provide different sets of functionality (though all at least meeting the base spec).  So you write your Java (or whatever), and run it in a JEE server.  You're a JEE developer who writes Java.

This is also exactly like saying you're a Rails developer.  People don't write Rails code, they write Ruby code, but they're still Rails developers.  Railos provides a framework for your Ruby to run in, along with a pile of helpful functionality.  You're a Rails developer who writes Ruby.

I am a ColdFusion developer.  I am also Railo developer.  I'm also a JEE developer.

I write CFML, Groovy, Java, JavaScript, and a pile of other languages.

So if you want TIOBE to list ColdFusion on there, then they should also list JEE and Rails on there.  They don't, they won't, and they shouldn't.  Period.  End of story.

</rant>

I've intentionally not linked to the TIOBE listings.  They're easy to find if you care, but they're pretty irrelevant.  Bordering on retardedly stupid.

Conversion, as you might imagine, happend right about 20:30.  The jaggies you see on the MySQL line are from me manually reducing and then reincreasing it's memory caches.  I wanted to make sure it was mostly out of the way while I was converting, and willing to pay a little performance to get it.  Unfortunately it makes the charts a little dirtier, but oh well.

The actual migration process was really simple.  I spun up a Railo instance on my home computer, configured the server settings, set up my DSNs and mappings, and then shut it down.  Then I stopped Tomcat on my production server, moved the WEB-INF folder out of the way, rsynced up Railo's WEB-INF from my home machine to take it's place, and restarted Tomcat.  Done.

As for the CFML itself, I ran into a very small number of distinct issues, though they manifested in different ways:

• Railo doesn't support the column-as-array notation for queries that ColdFusion does (e.g. arrayMax(query["column"])), which I had used extensively in building Google Charts.  Fortunately they expose valueArray to compliment valueList, as well as supporting a string (static or dynamic) rather than just the reference (all CF allows).  This change made most of the instances cleaner, though you have to use a temp variable if your query isn't in an implicitly referenceable scope or nested within a complex structure, because the string must two-part.
• Railo doesn't support escaping keywords in queries of queries.  Fortunately it's not as anal about keywords (e.g., allowing "get"), but if you want to alias a column to "count", you're screwed.  Interestingly, you can happily select from a column named "count", just not alias to it.  It also has some weird issues when combining aggregation and union on timestamp fields (they get truncated to dates).
• Railo arrays don't support the .subList method from java.util.List.  It's implemented, but is hard coded to throw a RuntimeException.  I beat this via a subList UDF:

  <cffunction name="subList" output="false">
    <cfargument name="a" />
    <cfargument name="s" />
    <cfargument name="e" />
    <cfset var aa = [] />
    <cfset var i = "" />
    <cfloop from="#s + 1#" to="#e#" index="i">
      <cfset arrayAppend(aa, a[i]) />
    </cfloop>
    <cfreturn aa />
  </cffunction>

  It doesn't carry the same semantic as List.subList (which returns a view of the original list, not a new list), but for my purposes it was sufficient.

• Inline CFMAILPARAM attachments that use a contentId must have the id manually wrapped with angle brackets as Railo doesn't do the wrapping for you like ColdFusion does.  Easily fixed, though this one was actually caught by an end user.  Oops.
• "url is not a valid unscoped variable name as Railo assumes it means the url scope.  You must either qualify it with a scope, or avoid the name.  "cluster" has the same problem.  As you might imagine, the url-scraping acquisition and cluster-based prioritization of PotD made these two names quite common, so I had to fix a lot of instances.  But it was my fault for being lazy and not scoping to begin with.
• Railo respects and enforces an "abstract" attribute on CFFUNCTION that requires the body to be empty (just like CFFUNCTION within CFINTERFACE).  I use an "abstract" attribute frequently for metadata inspection, but always implement the method with a single CFTHROW tag (since CF doesn't understand abstractness).  The error message Railo generates is misleading ("cannot nest CFTHROW within CFFUNCTION" rather than "abstract functions cannot have a body"), but once I figured out what the issue was fixing it was simple.
• imageSetDrawingColor accepts three comma-seperated decimal values (e.g., "128,128,256″ for a blueish hue), but Railo does not.  Easily fixed with formatBaseN.

All in all, a pretty transparent migration.  I'm quite pleased.  And now I'm in a position to get CFML-based ORM without having to fork over the $4,000 to upgrade to CF9, which is a big win for me.  I'm sure little stuff will probably crop up over the next week or two, but all the major pieces (and all the minor bits I checked) seem to have worked flawlessly.

Last time I was foiled by CFHTTP adding a spurious Content-Type header on GET requests, which breaks secure downloads from S3 (which is where I host all the content).  I reported the bug and it got fixed, but I hadn't had time to revisit the migration process so there it sat.  Until this evening, that is.

I'm glad to say that the issue with GET requests has been completely resolved.  The bleeding edge is also a lot smoother than last time I pulled down a new version, so props to those guys.  Setting up a migration test environment actually proved pretty straightforward, even with all the crazy Apache and OS integration PotD leverages.

As expected, there were errors on the first page load, but nothing some trickery with mappings and rewriting a couple query of queries couldn't fix.  After that, everything just worked.  Thumbnail generation, S3 access, emailing, everything.  Except that it wasn't everything.  Turns out that exactly the same problem I had with GET requests before has no manifested itself with DELETE requests.  So I'm again stuck.

The way PotD is implemented, images are spidered and pushed immediately onto S3.  Then they go through the filter pipeline, and many (most?) of them are deleted.  So being able to remove stuff from S3 is a pretty core feature, otherwise I'd have piles and piles of orphaned files up there, and that just costs me money for no reason.  Sadly, this makes Railo a no-go again, and leaves me with CF8 for a while longer.

I've actually got a lot of stuff in the works surrounding my personal sites and projects, but the CF to Railo conversion is one of the larger ones as well as the one with the largest potential impact on server resources (which I'm continually constrained by).  The move from JRun to Tomcat was a huge help, but I could definitely use more and Railo gives all apperances of being able to give it to me.  Also have some major WordPress infrastructure changes, a whole rebranding of this (my blog), and a few other corollary improvements.

The overarching goal is to simplify my URL space so I don't have as much interleaving between separate applications.  www.barneyb.com's URL space, for example, houses 3 different blogs, two static sites, and a pile of little CFML apps.  ssl.barneyb.com houses SVN, Trac, PotD, and several other CFML apps.  It's a mess, but that'll be a lot better, regardless of what happens with the CFML engine stuff.

<cfset myArray = modifyArray(myArray) />

instead of like this:

<cfset modifyArray(myArray) />

you'll be fine.  However, someone pointed out on the Railo mailing list that this behaviour is not constrained to UDFs.  Assignment behave the same way!  Yes, if you assign an array to another variable, you get a copy.  The only "assignment" that is exempt from this behaviour is if you use structInsert.

Consider this code:

<cfset a = [37] />
<cfset a2 = a />
<cfset s1 = {array = a} />
<cfset s2 = {} />
<cfset s3 = {} />
<cfset s4 = {} />
<cfset s2.array = a />
<cfset s3["array"] = a />
<cfset structInsert(s4, "array", a) />
<cfset arrayAppend(a, 42) />
<cfset System = createObject("java", "java.lang.System") />
<cfoutput>
<p>#System.identityHashcode(a)# - #a.toString()#               <!--- [37, 42] --->
<p>#System.identityHashcode(a2)# - #a2.toString()#             <!--- [37]     --->
<p>#System.identityHashcode(s1.array)# - #s1.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s2.array)# - #s2.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s3.array)# - #s3.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s4.array)# - #s4.array.toString()# <!--- [37, 42] --->
</cfoutput>

At the end of this code, there are five distinct arrays, one containing 37 and 42, and the other four containing only 37.  The blue lines create the four copies, and the red line creates a new "pointer" to the existing array.  Then when the green line executes the original array has 42 added to it, which only affects 'a' and 's4.array', because the rest are copies.

On Railo, arrays are universally reference types, so there would only be a single array in the above example.  This is consistent with most other languages.

Here's the snippet:

<cfset objConfig = {
  root = getDirectoryFromPath(getCurrentTemplatePath()),
  tags = objConfig.root & "tags/",
  com = objConfig.root & "com/"
} />

Yes, that actually works.  Let me repeat, NEVER EVER USE IT.  It is the devil incarnate, and only works because of a horrible implementation error in Adobe ColdFusion.  Note this is a ColdFusion bug, not a CFML language issue.  Railo implements struct literals correctly (as well as treating them as expressions instead of statements).  I don't know about OBD – the last time I used it there wasn't struct literal support at all, but it's been a while.

Railo has an issue with non-defaulted, non-required, numeric method arguments that are omitted from a call.  I added it as bug 147 in JIRA.

Turns out I was a bit incorrect – I'd forgotten that method was proxied by ColdSpring's AOP engine (which is exactly what's supposed to happen with AOP), and that's where the bug actually resided.  Railo was returning "[runtime expression]" as the default value for the argument within the function metadata, which ColdSpring was faithfully writing into the proxy method that it generates.

In any case, got a JIRA update from Michael to say it's been resolved, so the next build should have it fixed up.