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:
[webroot]/bin
folder(s)However, while my migrated Railo apps all seemed to continue running ok in development, I was hestitant about performing the switch in production.
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.
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.
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" );
}
This has been raised as Issue #78 in the Lucee issue tracker.
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.
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.
Raised as issue 119 in the Lucee issue tracker.
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.
Back to the top