В tomcat7+ сделано параллельное развёртывание - не надо ничего удалять, достаточно "правильно" именовать.

no56892Ну наверноя не правильно выразился, фактически надо обновлять не все приложение а отдельные классы.Распаковываем веб-приложение в каталог, создаём описатель контекста.
После обновления "отдельных классов" меняем тайм-штамп описателя - томкат перезапустит приложение, если это не запрещено настройками.

вадяэто как?В строгом соответствии с документацией .

no56892Это классы + изменения бд .Выделено мною.
Забудьте про свою "химию" - если требуется менять базу, то надо остановить использующие её приложения, сделать бэкап, накатить изменения и запустить новую версию приложений.

P.S. Нет, джедаю могут и налету, но джедаи не стали бы и вопрос задавать.

Или я вас не понимаю или вы меня или всё вместе ...

Если приложение меняет базу, то я не буду ничего делать на лету:
1. Получить уведомление о выходе новой версии;
2. Забрать новую версию;
3. Прочитать сопроводительную документацию;
4. Развернуть всё на стенде;
5. Отработать на стенде процедуру обновления.
6. Выполнить п.п. 3-5, даже если приложение не меняет базу.

Далее:
1. Выбрать время и оповестить пользователей о предстоящих работах;
2. Остановить систему, выполнить архивацию;
3. Обновить базу, обновить приложение;
4. Проверить, что всё работает;
5. Запустить систему и вывесить объявление об окончании работ.

P.S. Нет, джедаи могут и быстрее ...

P.P.S. Нет, в прошлом мне и самому приходилось накатывать срочные фиксы посреди рабочего дня, но:
1. До этого я много тренировался на стенде и многие вещи были отлажены применительно именно к нам, а не к сферическим коням разработчиков;
2. Я до сих пор считаю такие ситуации аварийными, а ответственность за создание таких аварийных ситуаций возлагаю на разработчиков.

вадяпример использования можешь привести?В строгом соответствии с докой
Вместо ROOT.war развёртываем ROOT##000.war.
Когда мы развернём ROOT##001.war, котяра воспримет это как новую версию и сделает следующее:
1. Развернёт новую версию;
2. Перестанет направлять входящие запросы на старую версию;
3. Когда старая версия приложения завершит обработку всех запросов - "свернёт" war старой версии, после чего этот файл можно будет спокойно удалить.

До появления параллельного развёртывания можно было делать так:
1. Развёртываем приложение (в виде war или католожной структуры) вне webapps;
2. Создаём описатель контекста;
3. Развёртываем новую версию в виде другого war или другой каталожной структуры;
4. Редактируем описатель контекста указывая путь к новой версии и сохраняем.
5. Котяра, обнаружив изменение описателя контекста начинает "свёртывать" старую версию, после чего стартует новую.

Параллельное развёртывание оптимизирует две вещи:
1. Фиксирует схему именования, что позволяет не велосипедить;
2. Позволяет плавно перевести обработку запросов со старой версии приложения на новую.
Разумеется, если в приложении случится какой-то раскосяк из-за параллельной работы двух версий в одной JVM - это будет проблемой разработчиков приложения, а не разработчиков Tomcat.

BlazkowiczСтарые сессии обслуживаются старой версией, а новые - новой. Когда активных сессий на старой версии не станет, можно смело удалять.Именно это я и хотел сказать, но, пожалуй, коряво выразился.

вадяно можно нарваться на одновременное использование старой и новой версии?
со всеми вытекающими последствиями?Не хотите рисковать или/и делать аудит/тестирование - используйте развёртывание вне webapps.
Минимизация даунтайма достигается за счёт развёртывания приложения "в каталог". Не по стандарту, но работает.
Вероятно - везде работает.
Второй способ ускорения развёртывание - вынесение общих (как правило - сторонних) библиотек в ${catalina.base}/lib.
Третий - аккуратное написание приложения