Cennest Technologies!

Hidden in the Whitepaper for Programming Table Storage are some BestPractices on how to code the ADO.NET Data Services or CRUD operations on Azure Table.

Here is a copy of the list extracted from various parts of the whitepaper

• The DataServiceContext object is not thread safe, so it is not meant to be shared amongst different threads. The DataServiceContext is not meant to have a long lifetime. Instead of having a single DataServiceContext for the life of a thread, it is recommended to create a DataServiceContext object each time you need to do a set of transactions against WindowsAzureTable, and then delete the object when done.
• When using the same DataServiceContext instance across all inserts/updates/deletes, if there is a failure when doing SaveChanges, the operation that failed is kept track of in the DataServiceContext and re-tried the next time SaveChanges is invoked.
• DataServiceContext has a MergeOption which is used to control how the DataServiceContext handles the tracked entities. The possible values are:
  • AppendOnly: This is the default value where the DataServiceContext does not load the entity instance from the server if it is already present in its cache.
  •  OverwriteChanges: DataServiceContext always loads the entity instance from the server hence keeping it up-to-date and overwriting the previously tracked entity.
  • PreserveChanges: When an entity instance exists in the DataServiceContext, it is not loaded from persistent storage. Any property changes made to objects in the DataServiceContext are preserved but the ETag is updated hence making it a good option when recovering from optimistic concurrency errors.
  •  NoTracking: Entity instances are not tracked by the DataServiceContext. To update an entity on a context that is not tracking will require the use of AttachTo to update the etag to use for the update and hence is not recommended.

context.AttachTo("Blogs", blog, "etag to use");

context.UpdateObject(blog);

context.SaveChanges();

When MergeOption on the context is set to AppendOnly and the entity is already tracked by a previous retrieve or add operation with the DataServiceContext object, then retrieving an entity again from server will not update the tracked entity in the context. So, if the entity on server has changed, it will result in PreCondition failure on subsequent updates/deletes.

• Due to a known performance issue with the ADO.NET Data Services client library, it is recommended that you use the table name for the class definition or define the ResolveType delegate on the DataServiceContext. If this is not used and when the entity class name is not the same as table name, query performance degrades with number of entities returned in the result. An example of using ResolveType delegate is shown below:

   

  

   

It has been  noticed that when these names are different, there is a fixed overhead of approximately 8-15ms for deserializing each entity received in a query

• By default, the value for the number of .NET HTTP connections is 2.  This implies that only 2 concurrent connections can be maintained. This manifests itself as "underlying connection was closed..." when the number of concurrent requests is greater than 2. The default can be increased by setting the following in the application configuration file OR in code.

• When a client sends a POST/PUT request, it can delay sending the payload by sending an “Expect: 100-continue” header.
  • 1. The server will use the URI plus headers to ensure that the call can be made.
    2. The server would then send back a response with status code 100 (Continue) to the client.
    3. The client would send the rest of the payload.

This allows the client to be notified of most errors without incurring the cost of sending that entire payload.  However, once the entire payload is received on the server end, other errors may still occur.  When using .NET library, HttpWebRequest by default sends "Expect: 100-Continue" for all PUT/POST requests (even though MSDN suggests that it does so only for POSTs).

In Windows Azure Tables/Blobs/Queue, authentication, unsupported verbs and missing headers failures can be tested just by receiving the headers and the URI. .   If Windows Azure clients have tested the client well enough to ensure that it is not sending any bad requests, clients could turn off 100-continue so that the entire request is sent in one roundtrip. This is especially true when clients send small payloads as in the table or queue service. This setting can be turned off in code or via a configuration setting.

Or in Config File

Before turning 100-continue off, we recommend that you profile your application examining the effects with and without it.

• Turning off Nagle may help Inserts/Updates

We have seen that turning nagle off has provided significant boost to latencies for inserts and updates in the table service. This is usually true if you have a large number of small entities. However, turning Nagle off is known to adversely affect throughput and hence your application should be tested to see if it makes a positive difference.

This can be turned off either in the configuration file or in code as below.

In Code:  ServicePointManager.UseNagleAlgorithm = false;

Config file:

• During development phase, it may be required to delete tables regularly. Currently, it takes at least 40 seconds before a deleted table can be recreated again. It may be beneficial to design the application such that the table names are suffixed with an id or version each time. This would circumvent the need to wait before a table can be recreated after a delete. However, this requires that ResolveType be set to overcome the performance bug in ADO.NET Data Service client library which affects query scenarios where the table name is not the same as the entity class name.

Hope these tips stay with you as you start up on Table Programming in Azure!!

Anshulee