In the simplest optimistic concurrency scenario the client says “If the resource is not in the state I expect it to be in, then fail.” In that case all that is needed is an etag that describes the state the client is expecting (e.g. the etag returned on the last GET). If the etag the client submitted and the resource’s current etag don’t match then the request fails.

Nice and easy and no need for a timestamp.

I disagree with your new description of what I thought you meant the first time. (Rechecking that sentence…yes, I think it’s right.) It could indeed be considered OCC, but your details aren’t quite right.

In OCC, the server gives the client a token (maybe the server’s timestamp when the last write took place, a UUID, or the user-visible record itself) which the client is supposed to return unmodified along with the new record. Its conflict detection can just do an equality comparison.

In this algorithm, the clients would be keeping a “last modified” timestamp that they update with their current time whenever the user actually writes a record. It’s not necessarily used by the server’s conflict detection; as you say an etag is fine. But it is used in the merge; the freshest record wins. (And as we’ve both said, it’s comparing different machines’ timestamps, so if their clocks are out of sync, bad stuff happens.) You need the timestamp here; etags give you no way of determining freshness.

What you implied in your comments is a more traditional optimistic concurrency scenario where a writer checks the last modified date to see the server state has changed more recently than the client’s last update. In that case the PDA’s clock would matter but since the PDA has to be on the net to make the update one assumes it can avail itself of NTP to make sure it’s clock is reasonably accurate. An alternative strategy are etags which don’t require a clock but that’s another story.

But yes, I agree with your general statement that it’s important to choose your merge strategy with care.

And, mentioning wikis, I’d also suggest that conflicts tend to be rare enough in practice that most folks won’t run into the conflict message all that often (hence the ‘optimistic’ in optimistic concurrency) and when they do the other person’s changes are more likely than not in a different part of the article then they are working on. But even then I’d point out that the kind of people who can handle merges on wikis are a tiny percentage of the computer using public.

But as I say in the article the point isn’t that optimistic concurrency is bad. There are many wonderful uses for optimistic concurrency but implementers need to keep in mind the inherent difficulties normal people have in dealing with merging and make sure they are prepared to handle the consequences.

By the way, pcal, there will be many, many more occasionally-connected clients in 20 years than there are today. There are already many places in the world where computers run off generators, occasionally connected over phone or satellite. The lack of stable power won’t be solved soon, but that hasn’t stopped people from being excited about the Internet. And the OLPC project will introduce millions of occasionally-connected laptops. And even in the developed world, there are places without line-of-sight where wires are hard to run.

OC will actually still be necessary even in a completely connected world. The issue isn’t so much connectivity as the operational and functional limitations of locking.

But as for occasionionally-connected clients: 10-20 years from now, the whole notion will be very quaint. Why waste energy worrying about them? :)

Take comments on this blog, comments are posted using append rather than replace (E.g. this isn’t a comment wiki page). Append designs make it possible for multiple people to add data without conflict.

I mentioned in the article that when groups need to work on common data they will try to partition the data to make conflicts less likely. Good services will support this directly.

So, for example, rather than having one big comment field to provide customer information it would be better to have some kind of multiple record structure (possibly in a hierarchy but that’s probably overkill) that can be updated individually. You can think of this as ‘free form’ information about a client showing up as a series of cards where different members of the team can take ownership of their own card and update it at will.

But eventually you will run into data that simply can’t be easily made conflict resistant, for example, the name of the company may change or their primary address. But in general such data changes very infrequently and if there is a conflict that almost certainly means that something bad really has happened and the people involved should talk to each other (E.g. if 3 sales people think there are 3 different primary addresses for an account that probably means they need to talk).

There are no miracles but there are things service designers can do to make their services more off-line friendly but first they have to realize there is a problem. In too many cases I’ve run into service folks who think that once they sprinkle the optimistic concurrency pixie dust on their system they are done and all off-line/conflict issues are resolved. It a’int necessarily so.