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.
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
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.
See also CommunitySolution, TechnologySolution