Home > Azure > The context is already tracking a different entity with the same resource Uri in Azure

The context is already tracking a different entity with the same resource Uri in Azure

Recently I started working on Azure. I got to usage of Azure Table Storage.Generally I hate working on Backend system where I need to have information on index, join etc , Any way we are leaving behind the relational databases and started using Windows Azure Storage which has provided some additional benefit from cost and Maintenance view. Coming back to my topic, today i will discuss about one such type of error where we are developing application using Azure Table Storage(ATS). When we try to move data either from SQL Server or other data sources into ATS, You might encounter error like “The Context is Already tracking a Different Entity with the Same Resource URI”. What are reasons for encountering these problems, after couple of hours of searching , I came up with root cause of the error. Whenever we are moving data into ATS, you should consider proper design of RowKey and Partition Key. To know more about Row Key and Partition Key .Please follow this link . In a Nutshell, you Partition Key is nothing but set of entity are of same type. You will group set of entity by a Key which partitionKey. Within each Partition Key, you have set of Row Keys. We have ensure that data of row key generated should be unique for a particular. Apart from RowKey, there is Property for each entity in ATS, which is ETAG. Etag are used to know about entities which are Updated, It has value which is compare from Client to ATS, always Etag values must be matched whenever your updating Entity in ATS.Azure Table handles concurrent updates or deletes through optimistic concurrency using an ETag value that is changed each time an entity is updated. The TableServiceContext stores the ETag of every entity it is tracking and submits this ETag in an If-Match request header when an update is requested. Azure Table rejects the update request if the submitted ETag does not match the current ETag for the entity. This comparision is done automatically by ATS, since every action is REST model.

Here are trouble shooting tips, Based on Row Key Designing for my application, I came to conclusion that there are 2 rows with same RowKey for a particular Partition Key Always ensure that You dont have 2 Entity with Same Row Key, If there is situation like than try to concatinate RowKey with Some ID @ end of RowKey , so that ATS can differentiate 2 entities.

Another reason for Getting above Error is because that your deserialized type does not exactly match the Type of the tracked entity. Check Your Base Class whether it inherits from TableServiceEntity. Its must to have Base Class of your entity to inherit from TableServiceEntity.

Another Crude method to fix issue is Disabling the Change Tracking for Context. In order to disable change tracking you use the MergeOption.NoTracking option of the MergeOption enumeration
TableServiceContext tableServiceContext = cloudTableClient.GetDataServiceContext();
tableServiceContext.MergeOption = MergeOption.NoTracking;
and then tableServiceContext.AttachTo(tableName, entityName, “*”); where * means the force update of entity to the context using DataServiceContext.AttachTo() with an ETag of *.

Using above 3 trouble shooting approaches for fixing the error.


Categories: Azure Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: