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:

    <add name="MyDb" connectionString="Data Source=NzSqlServer01;Initial Catalog=MyAzureDb;User ID=joe;Password=bloggs;"
  providerName="System.Data.SqlClient" />

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:

  <Setting name="MyDb" 
    value="Data Source=tcp:e54wn1clij.database.windows.net;Database=MyAzureDb{0};User ID=joe.bloggs@e54wn1clij;Password=reallysecure;Trusted_Connection=False;Encrypt=True;" />

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: ConfigurationManager.ConnectionStrings["CeraDb"].ConnectionString), does Azure automagically know to look for a database called MyAzureDb1 or MyAzureDb2 based on the ServiceConfiguration file’s connection string, or will the web application’s code simply look for whatever’s in Web.Config and fail to correctly load-balance the database connections?





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 System.Environment.MachineName which can distinguish in code between instances once they’re started.

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.)


Leave a Reply

Your email address will not be published. Required fields are marked *