ParableOfTheBook

MeatballWiki | RecentChanges | Random Page | Indices | Categories

In the RealWorld, when two people reach for the same book on a table, grabbing it at the same time, conflicts are resolved through feedback--not locking and synchronization. Consider that if they both tug on the book, one person will let go first, allowing the other to keep it. Problems of course arise when both want the book at the same time, but communication normally resolves this (between adults acting in GoodFaith; interfaces for children or attackers may have different requirements). For example, "Oh, sorry, could I have the book for a minute. I just wanted to look something up quickly." "Sure. No problem."

In online environments, it is often sufficient to indicate that the objects in contention are in contention. An additional, secondary CommunicationChannel (like a chat session), should provide all the ConflictResolution required. This will result in a simpler protocol and a simpler UserInterface.

Some might respond that it would be better to just prevent interacting with an object once it's in use by someone else. Note that this would require a very annoying interface, as one might start using an object before one receives the conflict notification. That is, as both clients have sent notifications, should both clients lock out the object (resulting in a dead object)? Should they both drop it (unilaterally aborting both users' actions)?

A better move might be to demonstrate that firstly, the object you are controlling is contended for, and secondly, the current status of the object to other people (say, where it currently is).

Another case is when one user grabs an object before she receives notification that it's been destroyed by the foreign client. In this case, it's best to restore the object, even if the first user intends to destroy it as well.

Notice that the only way people will both grab for the book at the same time in the real world is if they aren't paying attention to each other. With groupware, often the case is that they can't even see each other. Therefore, one should demonstrate to the foreign client what the local client is doing, say by notifying the other client of current actions. Thus, two users can "get out of each other's way."

A warning, however. Unlike a book, if the users can both simultaneously change the state of an object independently of each other, then the object isn't analogous to a book. In this case, you can either enforce dependencies, allow desynchronization, or lock the object.

A good resolution is to constructively allow desynchronization by transparently duplicating the resource once desynchronization has been detected. That is, give each user her own book. This way, neither user loses data and their actions are not interrupted.

CategoryInterfaceDesign

Just two months before I hurt my brain to come up with this idea, it was published. Only goes to show you how much time a good literature search can save. :( -- SunirShah

References

Chen, D. and Sun, C. (1999). A distributed algorithm for graphic objects replication in real-time group editors. In Proceedings of the international ACM SIGGROUP conference on Supporting group work, Phoenix, Arizona.

ParableOfTheBook

References

Discussion