Avoiding concurrency issues in a web based application

Question

Consider a web application where students can book a room. Now there could be scenarios where multiple students can book the same room leading to data errors. How to avoid this kind of thing?

My Thoughts:
The rooms booked by the students will be stored in a database. So if I use the functionality of the transaction provided by the database, that should be enough to handle it
I am not sure if the transaction code written in the web application, say in java language, needs to be put in a synchronized block?

Answer 1

It's effectively impossible to categorically answer this question; The "correct" way depends on your implementation, tools, languages and desired user experience.

There are, however, some common models for both user experience and implementation. The most common models I've seen in your specific scenario are:

Pre-allocation, where selecting the room as a candidate for booking causes the Webapp to 'lock' that room for a set period of time, giving the user a chance to complete their booking. This is annoying if people often select rooms then don't complete their booking, as it means that rooms will be unavailable to book often (but never get booked).

Transaction Locking, where you attempt to book a room and allow transaction exceptions from your DB to indicate that it's already booked. This is annoying if rooms are in high demand and people tend to try to book concurrently; They'll end up getting to the end of the process and be irritated.

If your system will have a single web server, I would probably lean towards the former method with a short timeout. Have the specific room selection be made at the end of the process (So the time between selecting a room and completing the booking is as short as possible). Assume users who are at that state will be completing their booking, and that it won't take long, then set the timeout accordingly. Then, control concurrency with a global, thread-safe pool and lean on your language's safe concurrency access model to control who wins in a contention scenario.

Answer 2

In order to handle the logic in your database, you have to correctly lock an entity, while doing a check whether your reservation is present or not, and then writing to the database. If you have done so, you can release the lock.

This way you'll get consistent data, so that there is no way, multiple reservations are made.

Doing it like this, you don't need business logic to handle locking. You just receive some return value, and then you have to decide what to do. Either tell the user that the reservation is a success, or else a new reservation has to be chosen.

Of course you can do the locking also in the business logic. In that case, you don't have to lock the database. As you mentioned, you would need a synchronize block. Inside this block you do the check and write to the database.