ETag's, Optimistic Concurrency and SSDS

Jeff talks about upcoming ETag support in SSDS

The long-term "storecast" — Sun, 22 Jun 2008 10:44:13 GMT

Jeff just sent me a note indicating that he has a post on the upcoming ETag support in SSDS. To be clear

re: ETag's, Optimistic Concurrency and SSDS

mamund — Sun, 22 Jun 2008 20:03:30 GMT

Good to see ETag support is coming for single entities. I'm looking forward to exercising this cool new feature.

It is also important that ETag support be added for queries. When you think about it, ETag for queries is very valuable as these queries can consume much bandwidth and reduce performance when you send repeated data between client and server.

re: ETag's, Optimistic Concurrency and SSDS

jcurrier — Mon, 23 Jun 2008 19:04:33 GMT

Mamund,

Let me make sure I understand your request first on the query side. Are you suggesting that we issue a ETag that represents the query result or over the indiviual entities within the result?

We already do the latter (that value will be in the Version property element in the results). The former would be pretty expensive to implement within the service.

Did I understand your request or is there something I'm missing?

--Jeff--

re: ETag's, Optimistic Concurrency and SSDS

mamund — Tue, 24 Jun 2008 22:25:10 GMT

Jeff:

Thanks for the reply.

Yeah, ETags for list queries is what I'm looking for. I think the way to do this is to compute the ETag *after* the query. This is what I do with results from my local SQL server:

Executing the query results in a block of XML. Hash the XML (MD5 is sufficient) and use that as the ETag.

This kind of hashing is cheap and effective.

Optimistic Concurrency with SOAP in SSDS

Sun, 29 Jun 2008 23:47:26 GMT

In my last post I described how ETag's can be used in the upcoming sprint 3 version of SSDS. In this