Let suppose we have an API to book tickets. There are 2 controller methods, one to check if the seat is already booked or not, another to book the seat. If 2 users simultaneously try to to book the same seat, then the first method will allow to book the seats. How is it going to handle the seat bookings now, running the requests in multiple threads parallelly?

CodePudding user response：

If concurrency is critical, you can use a message broker

There are many options but the ones I know of are "Azure Service Bus", RabbitMQ, or NServiceBus

You can map each "Receiver" to an airplane

But this might be an over engineered solution depending on your project.

CodePudding user response：

Let suppose we have an API to book tickets.

Okay...

There are 2 controller methods, one to check if the seat is already booked or not, another to book the seat.

So far, so normal.

If 2 users simultaneously try to to book the same seat, then the first method will allow to book the seats.

That depends entirely on how your underlying booking service's persistence store handles concurrent requests.

• If you're using a SQL database (MS SQL, MySQL, Oracle, PostgreSQL, etc) then you need to wrap the critical section of your SQL code in TRANSACTION statements with a COMMIT at the end, that way the RDBMS will handle the ACID-compliance for you.
  • For example, all of the above RDMBS will let concurrent IO to different unrelated rows happen in parallel because there's no conflict, but they will "sequentialize" the operations if two separate SQL transactions will affect the same rows, this is how they ensure ACID-compliance.
  • If you're using Entity Framework then unfortunately it's more complicated because EF doesn't generate a single long SQL statement batch: it (usually) executes single statements and ping-pongs between C#/.NET code and SQL, so you need to be careful. For this reason it's important (and often far simpler) to use a PROCEDURE instead of having EF do it).
• If you're using an in-process in-memory then without using lock statements to guard critical-sections - as well as using Concurrent-safe collections (like ConcurrentDictionary) appropriately.
  • The System.Collections.Concurrent types are not magic (they should be renamed "reduced-locking collections" imo), and you still need to understand how they work and what they do-and-don't-do (there's no ConcurrentList<T> type, for example - think about why that is).
• If you're using another external service as your back-end then you don't need to worry about it because handling concurrent operations is their problem.
  • Unless you're using an external service that doesn't offer any way to be transactionally correct, in which case then you will need to restrict concurrent operations in your own code, which won't easily scale (because in-memory techniques are fast, but don't work when your application is deployed over multiple web-server boxes).

How is it going to handle the seat bookings now, running the requests in multiple threads parallelly?

That's your problem to handle, not ASP.NET's.