Last December, one of the busiest months for most developers, almost everyone in the Railo team took the time to create a video message for all Railo users, contributors, friends, and clients. This video is now online, wishing you a Great Railo New Year!

Mark Drew, CEO of Railo Technologies Ltd in the UK, decided to write a book about Railo. When his idea got accepted by publisher PacktPub, he asked the rest of the Railo team if we wanted to write one or more chapters as well. I immediately said yes, and then found out that even writing one chapter of a book takes a huge effort. So I researched, I wrote, and even learned some new stuff while I was writing. It was a great experience to write for something that I am already passionate about. Trying to make the reader enthusiastic, while not being too techy all the time, was a nice challenge.

Mark, and also Gert Franz and Jordan Michaels, did a great job there! The book is absolutely a must-read for anyone using Railo, and wanting to learn about Railo! It not only covers CFML basics, but goes into all areas to get the most out of Railo Server.

Read more about, or buy the Railo 3 for beginners book at packtpub.com!

I recently had to dive into errors from one of our most busy web applications. The errors came from SQL Server, saying "Transaction (Process ID 51) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.".

This error comes from SQL Server, and more or less says "I could not execute your query, because it got in the way of another query". Veeery simply said, I know.

First thing I did, was asking the Railo team whether we could create a new option in the datasource screen "retry deadlocked query", with a number indicating the maximum number of retries. Initial reactions were positive, so I added a feature request into the Railo JIRA.

But, problem still remains for now. In my situation, it was always a SELECT query which was chosen as the deadlock victim. Now, I did a lot of googling and reading about preventing or circumventing this problem, and the most common answer was "use Read Uncommitted with your select statements, if you don't mind dirty reads". After discussing a bit at the office, we decided we don't mind, since we couldn't think of a really problematic scenario with it.

So, we had to change all select queries from...

I parsed the stats today which I keep for my Railo ExtensionProvider. This provider is the CFC which allows people to download and install the Railo extensions I made.

Since november 2010, the stats are as follows:

At the Railo team, we wanted to schedule regular meetings with the team. Normally, you would just pick a date and time, and you're done. But that's not so easy with the Railo team, since we live all around the world. Our main developer Michael therefor created a "tea(m) time" page where we can see what time it currently is for all the team members. At second glance, it suddenly struck me that I never saw this kind of timezone usage before:

#LSDateFormat(now(), "long", getLocale(), tz)#

where tz is a timezone string like "Australia/Perth". So I looked it up in both the Railo wiki and the ACF documentation, to find out that I just hit another hidden gem in Railo!