Deployment has the following phases:

The following sections describe these phases, and the JMS messages that the DeploymentManager sends to coordinate each phase across multiple deployment servers.

Deployment Start

When a call to the deploy() method of the DeploymentManager is received, the following actions occur:


After the threadBatchSize number of Marker objects are written, deployment enters the pre-deployment phase. With a full deployment, all repository items are deleted during this phase from the target repositories. Depending on the configuration (specifically, when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum option is enabled), all files can also be deleted from the target virtual file systems.

When this phase is complete, the DeploymentManager sends an ADD_UPDATE_PHASE message that triggers the start of the Add/Update phase.


This phase begins when an ADD_UPDATE_PHASE message is sent to a deployment-specific JMS topic. The message contains the ID of the deployment associated with the message. Instances of the DeploymentManager on each server are subscribed to that topic and begin processing on receipt of this message; this includes the DeploymentManager component on the server that manages the deployment process.

During this phase, the following actions occur:

When these actions are complete, the Marker item status is set to ADD_UPDATE_COMMITTED.

If an error occurs, the current transaction is rolled back. In a separate transaction, the Marker status for the item that failed in the current batch is set to FAILURE. The deployment’s failureCount property is incremented, and the Marker is removed from the worker thread’s list of items to operate on. The transaction is restarted from the beginning, skipping the item that failed. When the failureCount is greater than the maxFailureCount property configured in the DeploymentManager, the entire deployment fails.

After the management thread determines that the status of all Markers is ADD_UPDATE_COMMITTED, it starts the next deployment phase.

Reference Resolution

During this phase, all repository items with an action of add or update that contain references to other items, either a single reference or a collection of references, are resolved. To start this phase, the management thread sends a REFERENCE_UPDATE_PHASE message to the deployment-specific JMS topic. As in the first phase, each DeploymentManager starts all its threads and begins querying the deployment repository for work.

At the end of this phase, each Marker that has been processed has its status changed to REFERENCES_COMMITTED. Any Marker whose action is delete also has its status changed to REFERENCES_COMMITTED.

For file assets, this deployment phase is ignored.


This phase starts when the management thread sends a DELETE_PHASE message. All worker threads are started, and each one requests a series of Markers to process. In this phase, only Markers whose action is delete are processed. For those, the specified items are deleted from their repository. If an error occurs, the transaction is rolled back and all Marker statuses are set to FAILURE.

When all deletions are complete, control returns to the management thread, which sets the deployment’s status field to DATA_DEPLOYMENT_COMPLETE.

Destination Synchronization

During this phase, all destination repositories are synchronized by invalidating the caches for all the repositories on the target instances.

Note: For large file deployments in certain configurations (when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum option is disabled, or on the second apply phase of a switched deployment when Oracle ATG Web Commerce Content Administration is being used), operations that occur on the target can be time consuming.

Deployment Completion

The management thread sets the status of the deployment to DEPLOYMENT_COMPLETE and sends a COMPLETE_DEPLOYMENT message to all the DeploymentManager components. If the purgeDeploymentData flag is true in the deployment repository item, the Marker and deploymentData items are removed from the repository before the status is set.