This content has been marked as final. Show 4 replies
So here is how ATG deployment will work.
if you are using switching datasource, then the deployment will deploy the content on your passive schema first, and if the deployment is successful then it will switch the passive to active and active to passive and deploy on the second schema.
So if you are having catalogA and catalogB, and catalogA is active and B is passive, so deployement will first happen on B and then after switching B will become active and A will become passive and then content will be deployed on A.
ATG switching datasource will take care of deploying and synchronizing each datasource.
So after deployment is successful each datasource will have the updated content.
But if you are using any custom code to deploy some changes manually then you might need to use switching datasource in your code and deploy and switch datasources.
Yes, both datasources will be in synch. A switch deployment setup has two databases - one is active (or online) whose data is being used by the target site (i.e. production site) e.g. CatalogA* and another that is inactive (offline) with respect to a deployment target e.g. CatalogB*.
During the CA deployment for Repository assets, they are first updated on the site's inactive database (*CatalogB*) while the site's live database (*CatalogA*) continues to run undisturbed. When updates to the inactive database CatalogB* are completed, the site's SwitchingDataSource component switches its underlying data source to the updated database CatalogB* and the newly inactive database CatalogA* is updated to reflect the same deployment. This way both remain in synch.
Similarly for file assets, they are first updated on the target site's inactive directory while the site's live directory is being used. When updates to the inactive directory are complete, then the site switches to it and the inactive directory becomes the live directory and vice-versa. The newly inactive directory is then updated to reflect the same deployment.
Your ProductCatalog repository would be configured to use the SwitchingDataSource via some config layer overriding its default datasource:
Now the SwitchingDataSource component has following typical configuration:
Then within each of the datasources component ProductCatalogDataSourceA and ProductCatalogDataSourceB you actually specify to what database each datasource points:
$class=atg.service.jdbc.SwitchingDataSource # Map of switching data source names to data sources components dataSources=\ DataSourceA=/atg/commerce/jdbc/ProductCatalogDataSourceA,\ DataSourceB=/atg/commerce/jdbc/ProductCatalogDataSourceB # Name of the data source that should be used on startup initialDataSourceName=DataSourceA # Repository used by the switching data source to store current datasource. # SDSRepository is Switch Data Source repository having just a single item with properties like currentDataSourceName, server and lastModified timestamp. repository=/atg/dynamo/service/jdbc/SDSRepository
#/atg/commerce/jdbc/ProductCatalogDataSourceA $class=atg.nucleus.JNDIReference JNDIName=java:/ATGSwitchingDS_A
SwitchingDataSource is configured on both CA and target server instances but the initialDataSourceName is not same on both the configurations. It ensures that first deployment is made to the inactive database on the target server. For every subsequent deployments, the currentDataSource is obtained from the state recorded in the SDSRepository.
#/atg/commerce/jdbc/ProductCatalogDataSourceB $class=atg.nucleus.JNDIReference JNDIName=java:/ATGSwitchingDS_B