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:
The DeploymentManager sends a
START_DEPLOYMENTmessage. No deployment engine processing occurs at this point; the message exists principally to allow custom integration with the deployment system.Note: if another deployment is in progress when the call to the
deploy()method is received, the second deployment is queued.A thread is spawned that manages the remaining deployment process. This thread is the main or management thread; there is only one instance, and it resides on the calling machine.
Control returns to the caller. The
DeploymentDataobjects that are passed into thedeploy()method are retained by the management thread. They should not be altered by any client code.In the management thread, the DeploymentManager writes
DeploymentDataandMarkersto the deployment repository. This process is controlled by the DeploymentManager where thedeploy()call was made.To write the data efficiently to the deployment repository, the DeploymentManager spawns no more than
maxThreadCountnumber of worker threads, assigning each threadDeploymentDataandMarkerobjects up to a maximum ofthreadBatchSize.Before starting the worker threads, the DeploymentManager sends a
MARKER_PERSISTENCEmessage.
Pre-deployment
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.
Add/Update
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:
All repository items whose action property value is
addorupdateare created.All properties with primitive types are set on items whose action is
addorupdate.Properties of repository items that are required references are set to a temporary dummy item. Only one dummy item of each referenced item descriptor is created; these are deleted at the end of the deployment.
Properties marked as
deployable=falseare not deployed.Files whose action is
addorupdateare copied to the responsible deployment agents.
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.
Delete
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.
