In che modo un sistema di prenotazione dei posti per cinema cinematografico impedisce a più utenti di riservare gli stessi posti?

Il metodo classico per fare ciò è usare un database transazionale (quindi non ci sono interferenze) e fare una allocazione provvisoria del posto a te che scade dopo un certo periodo di tempo (es. 10 minuti per i chioschi) che ti danno abbastanza tempo per pagare. Se la transazione (visibile dal cliente) cade o scade, l'assegnazione del posto può essere rimessa nel pool. (Tutte le modifiche di stato vengono elaborate tramite il database transazionale e una transazione visibile al cliente potrebbe richiedere molte transazioni a livello di database.)

Le compagnie aeree useranno un sistema simile (anche se molto più complesso a causa della necessità di gestire più gambe di volo!) per prenotare posti online. Immagino che il timeout sarebbe considerevolmente più lungo; i biglietti aerei di solito vengono prenotati più avanti dei biglietti per il cinema, e sono anche più costosi.

I 30 secondi che hai visto sono al giorno d'oggi spesso più simili a 15 minuti. Non credo ci sia una transazione di database attiva per quella durata.

Se dovessi progettare un sistema del genere, ecco come lo farei: Avere gli oggetti business Booking e Reservation . Le prenotazioni sono essenzialmente confermate (cioè a pagamento). Li memorizzerei nella stessa tabella DB e li distinguerei per un attributo o due.

Quando si recuperano i posti disponibili, si invieranno le prenotazioni e le prenotazioni.

Quando qualcuno seleziona un posto, crei una nuova prenotazione, mostrando così agli altri clienti il posto occupato. Una seconda prenotazione per lo stesso posto verrà rifiutata: l'aggiornamento o l'inserimento del DB non andrà a buon fine. Se il cliente conferma / paga la prenotazione, la trasferisci in una prenotazione. In un lavoro a lotti periodico, cancelli tutte le prenotazioni più vecchie di 15 minuti (o qualsiasi altra volta che dai ai tuoi clienti).

Ci sono almeno 2 processi aziendali coinvolti qui.

• Processo uno:

Mostra posti disponibili.

• Processo due:

Prenota un posto selezionato.

Poiché questi processi non si susseguono in modo smodato e poiché 2 persone possono selezionare la stessa sede, sorge il problema della concorrenza.

Se la progettazione del database assegna il vincolo di unicità corretto in modo che la combinazione di:

-TheaterID

-SeatID

-EventID

sono unici, quindi il database impedirà i duplicati.

Il seguente scenario è anche possibile ma verrà preso in considerazione dall'implementazione suggerita sopra:

Supponendo che sia possibile visualizzare una vista a griglia di un determinato teatro e un determinato evento:

1. Utente1 visualizza i posti disponibili (e ottiene i posti 1 e 2)
2. Utente2 visualizza i posti disponibili (e ottiene i posti 1 e 2)
3. L'utente1 parla un po 'con il cliente al telefono
4. L'utente2 va e prenota il posto 2 per il suo cliente
5. L'utente1 prova a prenotare il posto 2 per il suo cliente (perché è visibile sul suo schermo)
6. L'indice univoco impedisce al passaggio 5 di spostare i dati.

Quindi tutto ciò che devi fare potrebbe essere niente più design di database corretto e scelta corretta sui vincoli.

Sono possibili altri approcci più complessi, se lo si desidera, utilizzando le code di transazione. In questo caso, le richieste vengono scritte prima in una coda, quindi viene eseguito un processo ogni n secondi, ma ciò è difficilmente necessario o pratico nel tuo caso.

La parte davvero interessante è che cosa dovrebbe mostrare la griglia elenco per l'utente 1?

È possibile evitare le condizioni della gara se si ritardano l'assegnazione di posti specifici.

1. Raccogli le preferenze di posti a sedere dal cliente (numero di posti, prezzo, area del teatro, posti adiacenti obbligatori, ecc ...)
2. Salva le preferenze di postazione richieste in una coda
3. Le richieste di posti uno a uno vengono ritirate dalla coda, i posti assegnati in base alle preferenze e la prenotazione completata se i posti trovati.
4. Se la prenotazione è stata completata, informare i clienti e i biglietti postali; altrimenti, notifica al cliente che nessun biglietto corrisponde alle preferenze.

Va con la proprietà ACID del database - Isolamento. Il database utilizza i blocchi sui dati per evitare modifiche simultanee dei dati.

link