vor dem verlassen der Seite Daten speichern

[Tom]

Hello,

ich hatte Dich also schon richtig verstanden.

Hast du offensichtlich nicht.

Doch. Siehe https://forum.selfhtml.org/?t=216824&m=1487960

Ich würde nur nicht das Pferd von hinten aufzäumen.
Erst Stammdaten erfassen, dann Reservierung vornehmen, dann buchen.

Aber ein Aufräumscript benötigst Du dann nicht jedes Mal. Das reicht, wenn man das einmal am Tag laufen lässt.

Nein. Es muss sehr häufig laufen, damit andere Kunden die Plätze reservieren können!

Wann werden denn die Plätze wieder frei?
Richtig: nach einem Timeout.

Und für den Timeout benötigt man kein "Aufräumscript", sondern nur eine entsprechend formulierte Abfrage an die Datenbank.
Siehe benötigte Timestamps https://forum.selfhtml.org/?t=216824&m=1487954

Ein "Aufräumscript", dass dann ggf. auch noch Löschungen von Zeilen vornimmt in sehr kurzen Abständen laufen zu lassen, kann die DB in die Knie zwingen. Das Beste ist immer, wenn man bei solchen Vorgängen nur mit Selects und Inserts arbeitet.

Sonst kann ich, indem ich hunderte Sessions öffne und Tische blocke,

Wann ist denn enh Tisch geblockt? Vielleicht ist die Reihenfolge des Buchungsablaufs ja nicht optimal. Dann wäre es besser, die erstmal zu optimieren, bevor man weitere "suboptimale Verfahren" hinzufügt. Tausende von Ajax-Requests als "Medizin" gegen hundert richtig georndete Vorgangs-Requests... Was da wohl besser ist.

Wenn man die Zeiten passend wählt, ist Ajax also auch nicht unbedingt notwendig.

Doch. Wie willst du sonst dem Server Bescheid geben, dass der Browser die Seite noch geöffnet hat? Der Nutzer macht nicht notwendig normale Requests während des Buchungsverfahrens. Das Szenario habe ich schon beschrieben: Nutzer sucht seine Kreditkarten heraus.

Das soll er gefälligst vorher tun.
Also nochmal:

• Buchungsseite wird aufgerufen.

• Der Ablauf der Buchung ("Bedienungsanleitung") und eine "Statusleiste" wird angezeigt

• Der User gibt seine Stammdaten ein. Dafür benötigt er kein Ajax

• Die verfügbaren Plätze werden angezeigt.

• mittels JavaScript (scheint ja aktiv zu sein *höhö*) kann er jetzt mehrere
    freie Plätze markieren. Das findet lokal statt und muss nicht unbedingt
    schon mit dem Server abgeglichen werden. Mittels JavaScript wird in der
    Betrags-Zeile gleich mitgerechnet und er Endpreis angezeigt.

• Nun klickt der Kunde auf "Buchen".

• das Script prüft, ob die Plätze noch frei waren und bucht sie.
    Entweder: Quittung, oder:

Sollte ein Platz aus einer Gruppe zusammenhängender Wunschplätze nicht mehr frei sein,
  versucht dein Algorithmus, durch Kleine Verschiebungen im freien Kontingent die Plätze
  zusammenhängend anzubieten.

Jetzt kommt der einzige Kritische Zeitraum.

Der Kunde bekommt jetzt genau X Sekunden Zeit, zuzustimmen. Anderenfalls greift ein
  weiterer Timeout (den hatten wir noch nicht berücksichtigt) und due Buchung wird storniert
  und er er muss ggf. von vorne anfangen.

Das einzige, wozu ich Ajax (oder eine entsprechende JS-Funktion) einsetzen würde, ist die Aktualisierung der Anzeige, Da darf man aber vermutlich auch nur das Attribut "disabled" bedienen, da

Das belastet nur das Netz und den Server. Und wenn man genau überlegt, ist Ajax ja auch an eine Pollingrate gebunden. Mach die in Gedanken einfach mal etwas länger, dann bist Du schon beim "passiven Verfahhren" angekommen.

Was soll das sein?
Die Pollingrate sollte hoch sein, damit auch das Aufräumen in einem kurzen Intervall möglich ist.

Es muss nicht "aufgeräumt" werden, weil bei passend gewähltem Datendesign und Abfragen die Datensätze automatisch selektiert werden, die einen der Timeouts verpasst haben.

Das Ganze ist ohnehin Statistik.

Nehmen wir mal als Beispiel die Allianz-Arena.
Die hat laut Wikipedia im Moment 71.137 Plätze.

Die verteilen sich aber auf diverse Sektionen. Nehmen wir einfach mal an, es wären 12 gleich große Sektionen. Nehmen wir weiterhin an, dass sich Buchungen über Sektionsgrenzen hinaus nicht in einem Schritt erledigen lassen. Das wäre überall Usus.

Für jede Sektion läuft also ein eigenes Teilmodul des Buchungssystems. Die Rechnungsbeträge und der Kartenversand können ja trotzdem später auf eine Kundennummer zusammengeführt werden.

Es sind also prp Sektion 1428 Plätze zu vergeben.

Nehmen wir nun an, dass die Kunden im Mittel 5 Plätze pro Buchung bestellen. Dann sind wir bei 285 Buchungen. Nun könnten wir die Wahrscheinlichkeit der Kollision einführen. Nehmen wir also an, dass es 20% Kollisionen gibt (das ist enorm viel). Dann müssten sich diese ca. 57 Leute arrangieren. Wenn wir von einer "Offenzeit" von ca. 90 Sekunden für die eigentliche Buchung ausgehen, also von der Auswahl der Plätze bis zum "Ich-Will-Klick", dann müssten diese armen Leute also maximal 57*90 Sekunden versuchen, bis sie wissen, dass ihre Plätze nicht mehr verfügbar sind.

Ist natürlich Quatsch, weil das Programm im Hintergrund ja Kollisionen zu bereinigen versucht und die meisten sicherlich auflösen kann.

Bevor ich hier einen Server mit über Vier Millionen (71.137 * 60) Ajaxrequests pro Minute zumülle, arbeite ich doch lieber an einem vernünftigen Vergabealgorithmus.

Da würden mir z.B. einfallen:

• Stammkunden, die Plätze fallen sowieso schon raus
• Vorbestellungen, werden nach Eingang vorher abgewickelt. Durch "sanfte Verschiebungen"
    werden kleine Lücken freier Plätze automatisch zu größeren zusammengefasst
    -> "Defragmentierung"

Und nochmal:
in einer indizierten Tabelle einer Datenbank gleichzeitig hochfrequent mit Inserts, Updates und Deletes zu arbeiten, ist tödlich für den Datenbankserver.

Der OP sollte das Verfahren also so aufbauen, dass er während der Buchungsphase mit Selects und Insert sowie verlorenen Schlüsseln auskommt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg