A switching datasource is a concept fairly unique to ATG. When a business rolls over a few thousand changes from their content management system onto the live site, it can be a rocky transition. Any number of things can go wrong when trying to add that much data onto a production database.
To combat this, the creators of ATG implemented a switching datasource setup. Typically, there will be two production customer-facing setups, one active and one inactive. Clients go into the Business Control Center and add however many changes they want. These changes get saved on a publishing database, then are deployed onto the inactive production customer-facing setup in a ‘switch mode’ deployment. Then, in one transaction, the active datasource and inactive are switched. The inactive datasource with all the client’s changes is now the active datasource the site will run on.
Some businesses don’t purchase CA, so they have no use for a switching datasource. In that case, a single datasource is used and assets are managed from the ACC. Furthermore, businesses that have CA sometimes don’t use a switching datasource because they don’t have enough assets to make it worth their while. In that case, one datasource is used for ‘online mode’ deployments — meaning that assets are added immediately to the live site without the use of a secondary datasource. Switching datasources are meant for high-traffic setups where the performance and complexity savings are worth it.
Note: setups with switching datasources often still use online mode deployments for small changes.
The second option of only one datasource is a very common setup in the industry. It is faster, but there is more of a chance of danger when more data is moved around at a time. Switching datasources can handle a large data load and stay sturdy and safe.
Nice article, Peter. I just wanted to offer one point of clarification. Switching data sources are part of the DAS module, the foundations of ATG. This support was available long before CA was offered. You don’t need to use CA to exploit switching data sources.
I use switching data sources even in non-CA systems whenever (1) I have a lot of data to inject into a non-versioned repository and I don’t want that injection to effect the customer experience being offered up by the page serving instances, (2) the data being injected must be “all or nothing”, yet there’s too much to be reasonably contained within a single transaction, and/or (3) the information is being supplied over a period of time, yet I need to control it’s availability online as a single package.
The beauty of switching data source is that I can logically and physically separate the operation of the feed from serving up pages to consumers without the need for a single line of application code.
Again, nice article. Thank you for sharing this.
Mark