Archief - Concurrente reserveringen

De prefix is misschien niet volledig correct, maar het leek me het beste voorvoegsel dat bij mijn probleem past

Ik ben op het moment mijn broer aan het helpen met een web-project waarbij gebruikers dingen moeten kunnen reserveren.

Hoe wordt dit nu eigenlijk in het algemeen aangepakt? Ik wil niet dat 2 gebruikers tegelijk hetzelfde kunnen reserveren bijvoorbeeld, omdat ze van elkaar niet weten dat ze dezelfde reservatie op het oog hebben. In de Kinepolis bijvoorbeeld, hoe checkt dat systeem of 2 gebruikers niet dezelfde stoelen selecteren?

Je kan dat controleren op het moment dat je wil betalen, maar als 2 gebruikers tegelijkertijd op de "betaal"-knop drukken, gaat 1 van de 2 een melding krijgen "sorry deze reservering is bezet". Iets wat niet wenselijk is natuurlijk!

Het probleem doet zich vooral voor wanneer er gewerkt zou worden met een SMS-dienst. In de tijd van tussen het aanvragen van de reservatie-code en het invoeren van die code op de website, kunnen er al 10 anderen diezelfde reservatie-code opgevraagd hebben

--

Gelinkt hieraan, wat zou een goede manier zijn om betalingen in ontvangst te nemen? Voorlopig wordt er gekeken naar een SMS-dienst omdat bancontact redelijk duur is voor een beginnend project, en niet iedereen heet bijvoorbeeld paypal/VISA.

Ik ben redelijk zeker dat kinepolis het zitje locked van zodra een gebruiker die zetel heeft gekozen, ook al heeft deze nog niet afgerekend. Als een gebruiker niet snel genoeg de wizard doorloopt verliest deze de reservering en moet je opnieuw beginnen. Het nadeel is natuurlijk dat gebruikers zitjes kunnen locken en niet overgaan tot betaling, terwijl een andere potentiële klant te zien kreeg dat dit zitje bezet was op dat moment.

In jouw situatie kan je dit systeem ook gebruiken. Van zodra een reservatie-code wordt opgevraagd kan je die positie locken totdat die bepaalde code wordt ingevoerd op de website. Je kiest dan zelf de lengte van de periode waar die reservatie behouden blijft.

De kans op collisions blijft bestaan, maar is wel vrij klein geworden (namelijk de tijd die een sms'je nodig heeft om tot bij de server te geraken).

Klinkt als een goed idee, merci. Collisions zullen wellicht idd nooit volledig uit de weg geruimd kunnen worden, maarja.

Het wordt dan een afschatting hoe lang iets gelocked moet blijven. Er zal wellicht wel gewerkt worden met login-gegevens zodat er gemonitord kan worden hoe vaak iemand een reservatie locked en niet uitvoerd. Dan kan er redelijk gemakkelijk opgespoord worden wie er ofwel heel wispelturig is, ofwel misbruik maakt van het systeem.
Op die manier zou het geheel enkel nog ernstig verkracht kunnen worden als er iemand verschillende temp-email accounts aan gaat maken. Maar het risico is dan wel al verkleind alleszins ja.

Bedankt voor het antwoord

Je kan een reservatie ook voor vb. max. een uur locken hé, als ze binnen het uur niet tot de checkout overgaan dan denk ik niet dat ze het nog gaan doen... Afhankelijk van waar het over gaat uiteraard (bij Kinepolis zou het mij verwonderen dat ze zelfs al tot 1 uur reservatie gaan, ik denk dat het daar eerder rond de 10-15 minuten zal liggen).

BTW Als het gaat over een PHP/MySQL app zorg er dan voor dat je met transacties werkt (via InnoDB of een andere transactionele engine van MySQL).

Aangezien de Kinepolis reserveringsapplicatie een Flash app is vermoed ik dat ze een socket openhouden om te controleren of je de applicatie afsluit of niet, aangevuld met een expiration van inderdaad een paar minuten.

Sowieso moet je op het einde van de rit (de definitieve bevestiging en afrekening) een validation laten lopen om te zien of de reservatie nog mogelijk is.

Je moet je ergens ook afvragen of gans die opzet met locking wel nodig is en je app niet gewoon met een first come first go systeem werkt. Uiteindelijk gaat het er in de meeste gevallen om dat de reservatie verkocht raakt, aan wie dat is maakt niet uit.

In elk geval, als je met financiële transacties of locking begint te werken, zorg voor een degelijke unit en integration testsuite. Zou eigenlijk voor elke deftige web app moeten gebeuren, maar weet uit ondervinding dat het nog altijd meer uitzondering dan regel is.