Well the problem with having two clusters is simply the issue of having stand by hardware that is only used when you need to roll out a new application.
If you can afford to have 1/2 your hardware off line just for upgrade purposes, then, that seems like wasted hardware to me.
Another option is to have, say, 4 machines in your cluster.
At a low load time you bring 2 machines out of the cluster.
Upgrade those two machines.
Bring the machines up and switch over to the new 2 machine cluster.
If things go well, you then, later, upgrade the other two machines and you then have 4 machines in your cluster. If things don't go well, down grade the two machines and then add them back to the cluster. The idea is that by the end of the day you have 4 machines running the same version of the software.
The key there is that you have the ability to reduce your system capacity by half to perform the upgrade. But if you're a 24x7 site of constant load, that may not be practical.
In that case, it's not a container issue (neither of these are frankly) it's an overall architecture issue. You need to simply DESIGN the application to be upgraded.
Typically this is done through very loosely coupled systems able to be changed on the fly. Changing the tires on a moving car, so to speak.
And there are all sorts of issues with this, notably any client state that may be on a server at the time of switchover, and such.
I think there's hope in v3 that they'll be able to have a "site is down come back later" feature that the container can show while you're redeploying an application or some such thing.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=258129