Reservieren eines Theaterplatzes

Question

Denken Sie daran, ein Ticket für einen Film zu buchen. Es gibt x Anzahl der offenen Plätze, wenn Sie auf die Website kommen, möchte ich einen der Plätze für einen bestimmten Zeitraum reservieren.

Ich habe eine private interne API und eine öffentliche API. Die öffentliche API würde auf die Anwendung reagieren, die versucht, einen Sitzplatz zu reservieren, indem sie die interne API aufruft und diesen Platz dann in einen "Being Booked" Status setzt.

Mein Problem ist, dass ich gelegentlich zwei Personen den gleichen Platz buchen, und das führt dazu, dass eine Person alle ihre Informationen eingeben, und dann nicht in der Lage, ihre Registrierung zu beenden.

Ich habe versucht, meinen Code Thread sicher zu machen, aber immer noch die ungerade doppelte Zuordnung des gleichen Sitzes.

Ich rufe meinen Status-Update von meiner "Reserve" Methode als solche:

VisitStatusChangeResult visit_status_change_result = await ReserveSlotByLockedStatusUpdate(first_empty_seat);

dies ist die Status-Update-Methode, die ich versucht habe durch die Verwendung SemaphoreSlim Thread saftey hinzuzufügen:

private static SemaphoreSlim m_ReserveOnlineSlotStatusUpdateSemaphore = new SemaphoreSlim(initialCount: 1, maxCount: 1); 


private async Task<VisitStatusChangeResult> ReserveSlotByLockedStatusUpdate(VisitQueryResult first_empty_seat) 
{ 
    await m_ReserveOnlineSlotStatusUpdateSemaphore.WaitAsync(); 

    try 
    { 
    return await ChangeStatus(new VisitStatusUpdateModel 
    { 
     VisitID = first_empty_seat.ID, 
     CurrentVisitStatusID = first_empty_online_visit.VisitStatusID, 
     NewVisitStatusID = (int)VisitStatuses.BeingBooked 
    }); 
    } 
    finally 
    { 
    m_ReserveOnlineSlotStatusUpdateSemaphore.Release(); 
    } 

} 

Fehle ich etwas, wo sogar mit dem SemaphoreSlim zwei Leute auf dem gleichen Platz sitzen können?

Answer 1

Erstens, die Verwendung von speicherinternen Sperren zum Schutz des parallelen Zugriffs auf die Datenbankressource ist keine gute Idee - jede Datenbank hat ihre eigenen Tools für solche Dinge. Wahrscheinlich müssen Sie Parallelität in diesem Fall benutzen, etwa wie folgt aus:

update Visit set VisitStatusID = BeingBooked, ClientID = CurrentClientID where VisitStatusID = Free 

So wissen Sie die jetzt diesen Sitz buchen, und auch, wenn so passiert, dass dieser Platz schon nicht frei ist - dies Die Anweisung gibt 0 zurück (0 Zeilen geändert). Sie sollten dies überprüfen und entsprechend handeln (Kunden benachrichtigen, dass dieser Platz bereits belegt ist und die Plätze auffrischen).

Zweitens hat Ihr Schloss sowieso keine Wirkung. Nichts verhindert für zwei Clients, ReserveSlotByLockedStatusUpdateder Reihe nach, eine nach der anderen, und immer noch in Schwierigkeiten geraten, weil sie beide den gleichen Platz reservieren (es sei denn, Sie implementieren optimistische Nebenläufigkeit wie oben).