How do you handle/react to user input concurrency on the GUI layer?

Question

What are good ways to handle user input concurrency?

As the answers to this question already rule out database locking, how do you handle concurrent user inputs in general?

Is locking always a bad idea, even if it is not implemented by row locking? Are there best practices which are not use case dependant? What were your experiences with your strategies?

EDIT: I'm aware of handling concurrency on a data level through transactions: If two users simultanteously trigger a complex data change, transaction will handle it.

But I'm interested in handling or at least reacting to them on the GUI layer. What if the data change is part of a lengthy operation with user interaction?

Let's say two or more users are editing the same file over a web interface. At some point one of the users hits the save button. What happes to the other users?

• Will they get notified and/or forced to reload? Or will the eventually overwrite the changes of the first user?
• Shall I lock the file and prevent multiple users editing the same file?
• Can I put the whole editing process in a transaction (I highly doubt it, but who knows...)

What is the best way to handle this and similar situations? Are there any other strategies?

Answer 1

Look for how to handle "transactions" in whatever language/database API you are using. If you design these correctly it will handle it for you.

And to understand the theory, I'd recommend Distributed Systems by Couloris et al but there are lots of other good books.

Answer 2

Best strategy depends on what should happen from (business) process perspective - also important questions are what users would normally expect and what would surprise them least, and, of course, whether it is feasible to implement what they expect.

Your example of editing a file over web can be broken down as follows:

1. user1 checks out/gets/downloads/opens file v0
2. user2 checks out/gets/downloads/opens file v0
3. user1 makes changes to his copy of file v0
4. user2 makes changes to his copy of file v0
5. user1 saves file version v1 to server
6. user2 saves file version v2 to server

Note, that it is typical for web applications, and indeed for normal desktop office programs, too, that newest changes that user makes only become available (to others) after saving them, which means that it is not a case of having colleague's typing appear on top of yours in the copy of file you are editing.

A classic version control approach to this is that for user1 nothing changes as compared to normal desktop editing/saving process.

For user2, however, when he attempts to save v2 to server, the application must check whether there have been any changes to file version v0 since user last downloaded it. Since this is the case, a version control system would typically show him both versions (v1 and v2) on screen side by side, and let him mix them and save the resulting version (v3) to server.

For text files there exist a number of tools and systems both on Unix and Windows that try to automate the process so that if the areas of file edited do not overlap, the changes are merged automatically.

The alternative is locking file for user2 until user1 has finished editing it.

Putting editing in transaction is typically of no relevance. It is the final operation which attempts to overwrite existing file with new version, that is important. Editing happens independently on each users workstation and does not touch the server until last point (saving).

---

Your example is, by the way, distinctly different from another situation such as booking airplane tickets or booking an appointment to a doctor.

When booking tickets, there is a limited number of seats in a plane. It is possible, due to the fact that data transfer is not actually instanteous for more than one person to put a reservation to the same last seat on a plane.

Therefore, booking should be at least a 2-step process:

1. system shows free slots;
2. user asks for one of free slots (s1);
3. system tells user whether the slot is really still free, and if so, reserves it to you.
4. user completes booking.

The "really still free" step is because information on webpage user views is typically not updated realtime, so between steps 1 and 2, it is possible that another user has applied for the free slot.