I was trying to add my name to the list of attendees on the BarCampRDU Web site yesterday, and I found that regardless of the time of day, I couldn’t get in, because the wiki software that is used to manage the site grants an exclusive lock to the person editing the page for 15 minutes. After 15 minutes, the lock remains but someone else can steal it.
Using exclusive locks to avoid the lost update problem is painful, especially in Web applications, because users can easily navigate away from a page without providing any kind of signal to the Web application that the lock should be released. For example, if I go to the BarCampRDU page, click on edit, and close my browser window, I’ll keep my exclusive lock on the page for 15 minutes even though I’m not really editing it any more. This may seem like irresponsible behavior, but most people don’t expect clicking on a link to give them an exclusive lock on a resource. That’s not the Web way.
Optimistic concurrency control is the way to go in Web applications. It’s used in Mediawiki (as well as many other applications), and support for it is built into lots of persistence frameworks, including ActiveRecord and Hibernate. With optimistic concurrency control, things work like this:
- Person one attempts to edit a resource
- Person two attempts to edit the same resource
- Person one saves their changes
- Person two attempts to save their changes to a now stale version of the resource
- Person two is notified that a change slipped in behind them and that they need to reconcile their changes with person one’s changes
The nice thing about optimistic concurrency control is that the only time anyone is affected is if two people edit the resource and one actually slips in a change before the other. In all other cases, everything just works. The amount of trouble conflicts cause depends greatly on the type of resource in question. Even in cases where the content is complex (think of long wiki articles, for example), the user interface can make conflict resolution less painful through the use of diffs.
A quick Google search seems to reveal that somebody needs to write a tutorial that explains how to implement optimistic concurrency control in PHP, but I’m not the one to do it.
June 9, 2006 at 10:02 am
This should be a familiar concept to anyone who’s used to using a source code control system.
July 20, 2006 at 10:25 pm
Hi! You bring up really good points here; the reason why we used more pessimistic style locking is to avoid the issue of the user having to merge in changes. Merge conflicts are notoriously involved even for fairly technical people. Trying to make it easy for Grandma seems nearly impossible, but explaining that someone else is in the middle of using the resource felt straightforward. I’m definitely open to alternate suggestions, though.