Comments on: Realistic Concurrency

By: udidahan

udidahan — Fri, 18 Sep 2009 07:23:51 +0000

Simon,

Concurrency tokens can be useful but I’ve found that when going through these scenarios with users – understanding WHY they’re updating the data, what task they want to perform, what external, real-world trigger made them log into the system at this time, then the real task presents itself. And that task more often than not doesn’t require a concurrency token.

Hope that makes sense.

By: Simon

Simon — Thu, 17 Sep 2009 00:18:25 +0000

The problem I see with this is that the user is unaware that the data had changed after they submitted their change. Perhaps they only wanted to update the value if it was over a year old. Whilst in the time they were viewing the data on their screen, changing it and submitting it, someone else had snuck in and changed the data. For example, you wish to update an electricity meter reading only if it hasn’t been updated for longer than a month.

A concurrency token can help out here. For example, sending the RowVersion as part of the data to the client and back again, and then checking the concurrency token is still the same before applying the update.

What are you thoughts on that? Are there better ways to achieve this than using concurrency tokens?

By: » Database Level Conflict Resolution with Astoria

» Database Level Conflict Resolution with Astoria — Thu, 10 May 2007 14:10:27 +0000

[...] up on my recent post about the concurrency problems that we’re heading for with Astoria, and the way to avoid it by using business-level update semantics, I wanted to round out the [...]

By: » Dataset – O/R mapping rumble at TechEd MVP Dinner

» Dataset – O/R mapping rumble at TechEd MVP Dinner — Sat, 21 Apr 2007 18:20:54 +0000

[...] customer’s marital status, the other changes their address. At the business level, there is no concurrency problem here. Both changes should go through. When using datasets, and those changes are bundled up [...]

By: » Occasionally Connected Systems Architecture

» Occasionally Connected Systems Architecture — Wed, 04 Apr 2007 23:58:37 +0000

[...] changes to the server. This is handled on the server-side by the techniques I detailed in “Realistic Concurrency”, but it is critical to have the client pass the Units-of-Work it performed to the server for [...]

By: » Tasks, Messages, & Transactions – the holy trinity

» Tasks, Messages, & Transactions – the holy trinity — Sat, 31 Mar 2007 11:04:01 +0000

[...] written about how to do this before in regards to Realistic Concurrency, and the best example I have in terms of code is Better Domain-Driven Design [...]