News: Zero-downtime Deployment (and Rollback) in Tomcat; a walkthrough and a checklist

If you thought Tomcat could not get any better, you thought wrong. Tomcat 7 introduces what is called Parallel Deployment.

Simply put, parallel deployment is the ability to deploy more than one version of your web application in parallel, making all versions available under the exact same URL.

Think about this for a minute. If you have a new version of your application, you can simply drop it into the Tomcat that is running the old one and it will Just Work™. In fact, they will both work. Tomcat handles all session management and traffic routing between application versions. No need to restart Tomcat. No need to stop processing requests. No need to talk to your boss about downtime. No need for your boss to talk to any customers about downtime.

The people who created this feature chose a surprisingly easy solution for how to tell Tomcat what is an alternate version of what. All you have to do is tack ## onto the WAR’s file name. Simple and effective, if a bit odd-looking.

There are a few things to consider when you want to start using versioned WAR files with your Tomcat server. So before you go off and change the deployment strategy at your company, check off the list below.

1) Internal caches should be write-through and expire quickly2) You need sessions to be enabled3) Where does logging go?4) Disk files and directories need to be sharable5) No TCP socket listeners6) Your apps must be able to undeploy

I have been a content Spring user for many years and am quite happy to apply it more than liberally throughout my applications. It's a model I like and most of the applications built as or on open source solutions that I integrate seem quite happy with it as well.

Rod and the Spring team deserve a pat on the back for what they have done over the years for the Java community and I for one am happy they are still around, contributing to the community, even outside of their tool set and framework.

Running more than one version in production should be a situation that only exists for a few hours. Once the new version is deployed and tested to be known to work, the old version needs to be removed as soon as possible. Keep an eye on the number of active sessions on the old version and once that has dropped below a certain threshold, the old version is removed. If you have short session timeouts, this draining (as it is called) should last no more than half a day or so.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.