This section describes the phases of a deployment and the JMS messages that the DeploymentManager sends to coordinate each phase across multiple deployment servers.
Start Deployment Phase
When a call to the deploy() method of the DeploymentManager is received, the DeploymentManager sends a START_DEPLOYMENT message. 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 then spawned that manages the rest of the deployment process. This thread is the main or management thread; there is only one instance, and it resides on the calling machine. After this thread is spawned, control is returned to the caller. Note that the DeploymentData objects that are passed into the deploy() method are retained by the management thread. They should not be altered by any client code.
Then, in the management thread, the DeploymentManager begins the process of writing all the DeploymentData and Markers to the deployment repository. This process is controlled entirely by the DeploymentManager to which the deploy() call was made. To write the data efficiently to the deployment repository, the DeploymentManager spawns no more than maxThreadCount number of worker threads, assigning a number of DeploymentData and Marker objects to each thread, not to exceed threadBatchSize. Only the number of threads that need to be spawned are started. Just before starting the worker threads, the DeploymentManager sends a MARKER_PERSISTENCE message.
Pre-Deployment Phase
Once the threadBatchSize number of Marker objects have been written, the deployment enters a pre-deployment phase, during which, on a full deployment, all repository items are deleted from the target repositories. Depending on the configuration (specifically, when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum option is enabled), all files may be deleted from the target VirtualFileSystems in a similar manner.
When the pre-deployment phase is complete, the DeploymentManager sends an ADD_UPDATE_PHASE message that triggers the start of the phase in which data is actually deployed.
Add/Update Phase
The 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 is managing the entire deployment process.
During the add/update phase, all items whose action property value is add or update are created. In addition, all properties with primitive types are set on items whose action is add or update. Any 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 ever created; these are deleted at the end of the deployment. Any properties marked as deployable=false are not deployed. Finally, the marker item status is set to ADD_UPDATE_COMMITTED.
Concurrently with the repository item operations, any file whose action is add or update is copied to the responsible deployment agents.
If an error occurs, the current transaction is rolled back. In a separate transaction, the status for the marker 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.
Once the management thread determines that all marker statuses are ADD_UPDATE_COMMITTED, it begins the next phase of deployment.
Reference Resolution Phase
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. Note that any Marker whose action is delete also has its status changed to REFERENCES_COMMITTED.
For file assets, this deployment phase is ignored.
Delete Phase
This phase starts when the management thread sends a DELETE_PHASE message. Processing for this phase is similar to the previous two. 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 the Marker statuses are set to FAILURE.
When all the deletions are complete, control returns to the management thread, which sets the deployment’s status field to DATA_DEPLOYMENT_COMPLETE.
Destination Synchronization Phase
During this phase, all the 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 ATG Content Administration is being used), operations that occur on the target can be time consuming.
Completing the Deployment
Finally the management thread sets the status of the deployment to DEPLOYMENT_COMPLETE and then 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.
