nicht angemeldet
Hi!
Und eine Überbuchung sollte nicht stattfinden. Ein Ex_Lock auf die Tabelle wäre technisch ok, praktisch jedoch unbrauchbar, weil das Lesen blockiert wird. Du brauchst einen "Lese-Puffer" für Deine Besucher.
Damit kommt er meiner Meinung nach nicht weiter. Wenn er eine Transaktion startet, in der jemand x Mal $ding reserviert, dann sieht jemand, der die Tabelle liest, diese Reservierung nicht, weil alles was innerhalb der Transaktion läuft, öffentlich nicht sichtbar ist. Das heißt also, dass der nächste Besucher die gleich freie $ding-Anzahl sieht wie der, der grad dabei ist x Stück davon zu erwerben.
Ich würde es so machen, dass ich den Lesepuffer in eine normale Tabelle(n) lege, die Transaktionen jedoch eine transaktionssichere Tabelle(n). Jedesmal, wenn eine Transaktion abgeschlossen ist (commit), werden per Trigger die Daten aus der Transaktion mit dem Puffer abgeglichen.
Bleibt das Problem, das schwebende Erwerbungen sich nicht auf den noch verfügbaren Bestand auswirken und somit Überbuchungsversuche möglich bleiben. Eine schwebende Buchung muss bereits für alle anderen Besucher die Anzahl an verfügbaren $ding reduzieren - zumindest temporär, falls der Bezahlvorgang nicht erfolgreich verläuft. Da hilft ein Lock, doch alle anderen Besucher werden mit Wartezeiten genervt. Für eine Transaktion sehe ich nicht, wie sie in der Hinsicht helfen kann.
Natürlich hat das auch den Nachteil, dass sich einer über einen freien Platz freut und beim Bezahlen merken muss, dass ein Anderer schneller war. Aber wie das immer so ist im Leben: Wer zuerst kommt, mahlt zuerst *G.
Genau da soll ja aber nicht passieren.
Lo!