Tomcat Parallel Deployment: Deciding the Old Version's Role During a Schema Migration

Versioned contexts as a rollback path

Tomcat's parallel deployment feature lets multiple versions of the same web application run under one context path, using versioned artifact names such as app##001.war and app##002.war. The container routes new requests to the newest version while older versions remain deployed, which is the usual basis for an application-level rollback path.

The unresolved decision

Tomcat does not manage database schemas, so a migration and its reversal are handled outside the container. If the older version stays active during the migration, it may keep reading and writing rows under assumptions the new schema no longer holds. Stopping it avoids that risk but removes the rollback target and can interrupt sessions.

Session persistence adds a boundary: sessions shared across versions may carry attributes whose shape changed with the schema. Naming and deployment rules vary by Tomcat major version, so confirm them against the target release.

• Should the prior version remain active during the schema migration, or be stopped until it completes?
• What compatibility rules should govern session attributes shared between the two versions?
• Which deployment order preserves a usable rollback target without letting the old version write against the new schema?