What is the relationship between Web.Config connection strings and ServiceConfiguration connection strings in Azure?
I’m relatively new to Windows Azure and I need to get a better appreciation of how the Azure platform handles connection string configuration settings.
Assume I have an ASP.Net web project and this has a Web.Config connection string setting like the following:
I use this connection string for local testing and such. Let’s assume I have a ServiceConfiguration.Local.cscfg file that holds that same connection information.
Now I’m ready to deploy out to my Azure instance. My ServiceConfiguration.Cloud.cscfg file looks like this:
What I’m trying to get my head around is that if I have code in my web application that’s looking for a connection string called “MyDb” (for example, by calling this line of code:
Intrinsically, unless you code otherwise, all Azure instances are created equal. In your case, this means that the configuration for two or more instances of the same Web Role will be the same.
So, if you’ve sharded your database and want different instances to read different databases, you’ll need to get clever in your startup code and create something that allocates a shard to an instance. You’ve access to
There’s a few ways to do this. One might be to have a central registry in (say) table storage that keeps a log of the last-seen-time of an instance for a shard. A background process on the server periodically writes out to this log. Then, on instance start, check the last-seen-time for each shard — if any are “stale” (significantly older than the current time less the write interval) then the instance knows it can claim that shard for itself as the old instance has died.
(There are better ways to shard, however, generally around the data your system uses — e.g. by the largest table in your system.)