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 quickly
2) You need sessions to be enabled
3) Where does logging go?
4) Disk files and directories need to be sharable
5) No TCP socket listeners
6) Your apps must be able to undeploy

For the complete walk-through and details on the items on the checklist, read more on http://java-monitor.com/forum/showthread.php?t=1288

Kees Jan

Certainly interesting for Servlet users. OTOH, another SpringSource attempt to fight EJB 3 with their own piggyback Tomcat and their proprietary Spring framework.

another SpringSource attempt to fight EJB 3 with their own piggyback Tomcat and their proprietary Spring framework.

And there was me thinking this is in standard Apache Tomcat, which is not "controlled" by SpringSource, and equally available if using Tomcat7 under JEE ...

unlike EJB, spring is a light weight modular code that can be plugged into tomcat.

After previous experience with EJB, don't see any reason to go back and use it even though EJB programming model has improved.

After years of experience with Spring, DI and containers, I don't see any reason to use it. Not for Web/Servlet applications, even less as alternative to EJB 3.

Spring is just different. I thought we were past the silly lighter/heavier argument.

My main points are that 1) Tomcat can do this and 2) it is not for free; your app needs to not make assumptions about resource ownership. Nothing to do with Spring vs EJB. :)

Is Spring bashing warranted here? The article states they looked at adding the change to TC Server but found it was easier to commit the whole thing to Tomcat.

So the feature is in Tomcat, and it was supplied by Spring.

In this case, don't Spring deserve even a small thank you?

People may have their reasons to have a go at Spring but I can't see a reason in this post.

Mike

I think your waisting your breath........

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.

Good work guys....

When you deploy newer version of a WAR, are worker threads (max threads) and java heap is shared by them?

Old version will not work properly if newer version requires a database change.