Published
Friday, May 30, 2008 6:59 AM
by
mtaulty
Just like for batching, there's a great explanation of how concurrency looks in ADO.NET Data Services up here so this is just a basic example.
If I take the "Hello World" style service that I built back here then it does nothing about concurrency checking because, by default, when you build an entity data model with the Entity Framework tooling all of the concurrency options are set to "off".
So, if I make a request for a customer and trace it with Fiddler then I see;
You can see that I'm requesting the ALFKI customer and I'm just doing it from a browser as it happens.
Now, if I go and alter my entity data model a little bit to say that ( purely for instance ) I want to have concurrency checking done on the PostalCode, Country, Region, Address fields of the Customers entity type as in;
Then the next time I request that entity I see an ETag header being emitted that contains the value of my concurrency token;
and if I was to request lots of customers then I'd see these ETags move into the response data as in;
From there, if I make an update from a client such as using .NET code like;
static void Main(string[] args)
{
Console.ReadLine();
NorthwindEntities proxy = new NorthwindEntities(
new Uri("http://mthpvista/SecureSite/Secure/Service.svc"));
proxy.MergeOption = MergeOption.OverwriteChanges;
Customers alfki = proxy.Customers.Where(c => c.CustomerID == "ALFKI").First();
alfki.ContactName = "Modified";
proxy.UpdateObject(alfki);
proxy.SaveChanges();
Console.ReadLine();
}
then I can see that when we revisit the server we to make this modification we are using an If-Match header to check the concurrency token;
and if I was to cause a concurrency problem ( e.g. by changing the value of the city whilst the client code is running ) I'd see a 412 come back from the check on the If-Match header;
