Aquí hay al menos 2 procesos de negocio involucrados.
Mostrar asientos disponibles.
Reserve un asiento seleccionado.
Dado que estos procesos no se siguen de manera inmoderada, y dado que 2 personas pueden seleccionar el mismo asiento, surge el problema de concurrencia.
Si el diseño de su base de datos asigna la restricción de unicidad correcta para que la combinación de:
-ID del teatro
-SeatID
-EventID
son únicos, entonces la base de datos evitará duplicados.
El siguiente escenario también es posible pero será atendido por la implementación sugerida anteriormente:
Suponiendo que se puede mostrar una vista de cuadrícula de disponible para un teatro y un evento determinados:
- Usuario1 muestra los asientos disponibles (y obtiene los asientos 1 y 2)
- Usuario2 muestra los asientos disponibles (y obtiene los asientos 1 y 2)
- Usuario1 habla un poco con el cliente por teléfono
- Usuario2 va y reserva el asiento 2 para su cliente
- El usuario1 intenta reservar el asiento 2 para su cliente (porque se muestra como disponible en su pantalla)
- El índice único evita que el paso 5 conmute los datos.
Entonces, todo lo que necesita hacer puede ser nada más que un diseño correcto de la base de datos y una elección adecuada de las restricciones.
Otros enfoques más complejos son posibles si lo desea, utilizando colas de transacciones. En este caso, las solicitudes se escriben primero en una cola y luego se activa un proceso cada n segundos, pero eso no es necesario ni práctico en su caso.
La parte realmente interesante es ¿qué debería mostrar la cuadrícula de la lista para el usuario 1?