DAF Deployment uses multi-threading to move data from a source to a target server. The number of threads and the number of assets per thread are configurable, which allows you to tailor deployment performance to the hardware you have available.
In addition to using multiple threads, the work of deploying data can be split among many servers. This clustering capability allows the deployment mechanism to scale as the number of assets to deploy increases.
For repository assets, DAF Deployment uses the JDBC driver to connect directly from the source server (for example, ATG Content Administration) to the target database, allowing it to read and write repository assets without having to convert the data into an intermediate format. File system assets are transferred across the network using a TCP connection.
The diagram below shows the database, data source, and repository setup for instances of ATG servers using DAF Deployment.
Each development instance can have any number of source repositories (for example, an ATG Commerce environment could have a product catalog repository and a price list repository). Each development instance also needs to have a repository configured for each target environment. The example above shows one target -- production. For an example showing a more complex configuration with multiple targets, refer to Understanding Deployment in the ATG Content Administration Programming Guide.
Deployments are initiated by the /atg/deployment/DeploymentManager Nucleus component, which spawns a thread to start the deployment process, logs information about the deployment, and then returns control to the caller. The rest of the deployment happens asynchronously. First, data about the assets to deploy is persisted. Then a message to start the deployment is sent to DeploymentManager instances on the servers, each of which spawns a number of RepositoryWorkerThreads and FileWorkerThreads. The number of threads to use to process files versus repository items is determined by the ratio of files to repository items in the deployment.
Deployment transactions are performed in batches to avoid memory problems. After a given number of operations (specified by the transactionBatchSize value in the DeploymentManager), a thread attempts to commit its current set of operations as a transaction batch. If the commit succeeds, the thread requests another batch and continues until there are no more batches to process.
Transactions cannot span across threads.
