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 lets you tailor deployment performance to available hardware.

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 following diagram shows the database, data source, and repository setup for instances of ATG servers using DAF deployment.

Each development instance can have multiple source repositories. For example, an ATG Commerce environment might have a product catalog repository and a price list repository. Each development instance also must have a destination repository that is configured for the target environment. The previous example shows just one production target. For examples of configurations with multiple targets, see Understanding the Content Development Environment in the ATG Content Administration Programming Guide.

Each deployment is initiated by the Nucleus component/atg/deployment/DeploymentManager, which spawns a thread to start the deployment process, logs information about the deployment, and returns control to the caller. The deployment process continues asynchronously, as follows:

  1. Data about the assets to deploy is persisted.

  2. A message to start the deployment is sent to DeploymentManager instances on the asset management servers.

  3. Each asset management server spawns two types of threads:

    • RepositoryWorkerThreads process repository assets

    • FileWorkerThreads process file assets.

    The number of threads of each type is determined by the ratio of repository and file assets to deploy.

Deployment transactions are performed in batches to avoid memory problems. After a given number of operations (specified by the DeploymentManager’s transactionBatchSize property), a thread tries to commit its current set of operations as a transaction batch. If the commit succeeds, the thread requests another batch and continues until all batches are processed.

Note: Transactions cannot span threads.

loading table of contents...