Menu

As simple as possible, as complex as necessary

Migrating from ColdFusion to Railo to Lucee

2 March 2015
Lucee logo

Having documented the numerous issues I encountered moving from ColdFusion to Railo, I'm happy to report that the additional step of switching to the now defunct Railo's successor Lucee is a relatively minor one.

As a Windows/IIS user it was simply a case of:

  1. Downloading the Lucee jar files
  2. Stopping the Railo service
  3. Replacing the Railo jars with the new Lucee ones as detailed in the Lucee migration wiki page
  4. Updating the BonCode Connector .dlls in the [webroot]/bin folder(s)
  5. Restarting the Railo service
  6. Waiting a few minutes while Lucee took over and converted the installation.

However, while my migrated Railo apps all seemed to continue running ok in development, I was hestitant about performing the switch in production.

Unstable fork?

Lucee was announced as a fork of the latest official Railo version 4.2, but rather than from the latest stable release—4.2.1—Micha indicated that Lucee was in fact equivalent to the preview version 4.2.2.

This might not seem important, but as I described in an earlier post, serious issues with ORM transactions were introduced in the 4.2.2 patch, confirmed by a number of other ORM users.

Implicit flushing

One was a failure to flush the orm session implicitly at the end of a transaction block, requiring an explicit call to OrmFlush() at the end of the block.

In Lucee I found this bug was indeed present, but for some reason calling EntitySave() or EntityDelete() would also flush the session without the need for OrmFlush(). Quite an improvement for me as I generally use abstracted methods which include these calls, despite not being strictly necessary. For the relatively few cases where I was simply wrapping changes to entities in transaction{} blocks to persist them, adding an OrmFlush() wasn't too much of a chore.

Update 19 March 2015

I've since discovered the failure to implicitly flush the ORM session and persist changes only occurs when the entity being modified was loaded before the beginning of the transaction block. So this will work in Lucee:

transaction{
 myObject = EntityLoadByPk( "MyEntity",1,true ); //loaded inside the transaction
 myObject.setName( "something" );
}

However, the following change will fail to be saved to the database:

myObject = EntityLoadByPk( "MyEntity",1,true ); //loaded before the transaction begins
transaction{
 myObject.setName( "something" );
}

Bug tracker

This has been raised as Issue #78 in the Lucee issue tracker.

Connection timeouts

The other more serious issue with Railo 4.2.2 concerned datasource connections. After running apps for several hours I would see exceptions indicating that ORM connections to the database weren't timing out despite being idle for much longer than the default 1 minute datasource setting. In the end these idle connections were being terminated by MySQL after its default limit of 8 hours, but Railo/Hibernate appeared to still have an unflushed session handle on them, leading to the errors when an attempt was made to re-use them.

The build up of these non-terminating connections at one point almost brought down our server - leading to the patch being rolled back pretty fast.

I was particularly worried about whether Lucee would exhibit the same behaviour in a live environment, despite not seeing any errors in development.

Straightforward workaround

I've found that Lucee does have an issue with datasource timeouts, but also that it is fairly easily remedied.

After some close monitoring of my ORM connections, I established that the timeout failures only happen when calling OrmReload(). New connections established after the call would time out after 1 minute of idleness as expected, but any that had begun before the reload would seem to become "detached" and just sit there until killed by the database 8 hours later. If there had been a few of these running or you made multiple OrmReload() calls, this could lead to a large number of open connections, perhaps hitting the maximum allowed by the database (apparently this is what we experienced with the 4.2.2 patch).

The workaround is simply to tweak MySQL a) to time out idle connections a lot sooner and b) increase the number of concurrent connections allowed: belt and braces.

Bug tracker

Raised as issue 119 in the Lucee issue tracker.

Should you migrate to Lucee if you use ORM?

I've been running a number of ORM apps in production on Lucee for several weeks now and am generally happy with it. There are certainly bugs I would prefer were addressed, although I'm not optimistic they will be any time soon.

But none has proved a show-stopper and as long as you are aware of the issues and workarounds, it would seem advisable to jump as soon as possible rather than cling on to the sinking ship that would appear to be Railo.

Posted on . Updated

Comments

  • Formatting comments: See this list of formatting tags you can use in your comments.
  • Want to paste code? Enclose within <pre><code> tags for syntax higlighting and better formatting and if possible use script. If your code includes "self-closing" tags, such as <cfargument>, you must add an explicit closing tag, otherwise it is likely to be mangled by the Disqus parser.
Back to the top