This morning we posted another Web seminar in the “Everything You Need to Know About Azure as a Developer” series. This one is all about Windows Azure Storage – specifically, blob storage and table storage. Here’s the link to the new session:
http://www.msdev.com/Directory/Description.aspx?eventId=1498
If you’d like the source code for the demonstration, you can download it here. Note that in the Web seminar I built the demo in Visual Studio 2010, but this version is built for Visual Studio 2008 (it’s easier to move a solution from 2008>2010 than the other way around!)
#1 by Sonald Duclair on November 2, 2009 - 12:08 pm
I just watched the video but there is one thing that I think is not quiet right in the section about creating azure tables. I understand that you want to create the tables once, but calling the FirstRequestInitialization.Initialize() method in application begin_request does not ensure that it gets called only once. It will get call on every request. I see that the FirstRequestInitialization class has a static property that will get set the first time to prevent the table creation code from executing on subsequent requests, but whenever the application restarts, the value will reset to defaults and the table creation code will execute again. I think one way to get around this is to store the table creation information outsite the scope of the application so that whenever the application restarts the code does not execute again. Also, application restarts happen more often that people realize.
#2 by Sonald Duclair on November 2, 2009 - 12:14 pm
Oh, I forgot to mention, great video. Very well presented. However, one thing I don’t like about Azure is how every request is over http. How on earth can saving a blog in this manner perform better than saving a file to a local drive? I am looking forward to seeing some performance test results.
#3 by bill on November 3, 2009 - 12:06 pm
Quite right, Sonald – as it stands, FirstRequestInitialization.Initialize() will get called each time the application restarts. Due to the stateless nature of Windows Azure, the only way to avoid this is to store the table create status outside the scope of the application, as you suggest. But then the next question is, where? You’d want it in the cloud, or at least someplace that your cloud app can reach. SQL Azure might be an option but I think ultimately that may be overkill…
The reason I say this is that if you try to create a table that already exists, you won’t get an error it will simply not create the tables again… BUT, according to the Azure team there is a slight performance penalty because there are exceptions being thrown they just don’t bubble up to our code.
So although you definitely don’t want to try creating tables every time you access a table (as some early sample code showed), I think the very slight performance hit you’ll take by attempting to create them at application restart is worth being able to keep all your table-related code inside your Azure app… FWIW this pattern (using FirstRequestInitialization.Initialize()) was first applied to Azure tables by Steve Marx in this blog post, and I haven’t seen anything since that suggests it is not an acceptable practice… Cheers!
#4 by Sonald Duclair on November 3, 2009 - 2:38 pm
If I was working with Azure tables this is how I would go about it to make sure that my tables gets created once and only once. I would first save the list of tables that I want to be created in my app settings (i.e. name=”AzureTables” value=”MyTable1;MyTable2;MyTable3″. Once my application launches, preferable in Application_Start, I would call a method that gets the list of tables (string gets split into string[]) and for each entry in the list I would check if the table exists, if not I would then create it. Whenever I need to create a new table, all I would then need to do is add the table name to my app settings in the web.config file. It’s a very easy implementation, especially with the code you already have to create the tables.
#5 by bill on November 3, 2009 - 10:30 pm
I agree, checking the tables before you create them would be ideal and appSettings is a good place to put them. However, unless I’m mistaken Windows Azure storage provides no simple mechanism that allows you to check whether a table exists or not. I would be happy to be wrong about this, though!