nicht angemeldet
vor dem verlassen der Seite Daten speichern
MudGuard
AugeHallo zusammen
es gibt ja im Body tag die Funktion onunload um JavaScript beim verlassen der Seite auszuführen. Doch würde ich gerne die Änderungen in einer sqlite Datenbank speichern die auf der Seite vorgenommen wurden.
Würd mich also freuen wenn mir jemand helfen könnte.
Also schonmal Danke dafür Gruß blander
-
Hallo!
Doch würde ich gerne die Änderungen in einer sqlite Datenbank speichern die auf der Seite vorgenommen wurden.
Ein paar mehr Informationen musst du schon preisgeben. Was hast du genau probiert und woran scheitert es?
Ein paar Fragen ins Blaue: Wie gedenkst du mit JavaScript auf die Datenbank zuzugreifen? JavaScript kann das nicht direkt. JavaScript im Browser hat selbst nur Speichermöglichkeiten wie localStorage und IndexedDB zur Verfügung.
Wo läuft also die Datenbank? Auf einem Webserver? Steht dir dort eine Programmiersprache zu Verfügung? Welche?
Üblicherweise reden Browser und Server über HTTP miteinander. Du könntest einen HTTP-Request zum Webserver abschicken. Das kann JavaScript mit XMLHttpRequest. Mit dem beforeunload-Event kannst du einen Dialog “Wollen Sie die Seite wirklich verlassen?” zeigen und damit Zeit für den Server-Request gewinnen.
Auf dem Webserver muss ein Programm bzw. Script die Daten natürlich entgegen nehmen und in der Datenbank speichern.Nun aber genug der Spekulationen, jetzt bist du dran. ;)
Grüße
Mathias-
Hallo,
Mit dem beforeunload-Event kannst du einen Dialog “Wollen Sie die Seite wirklich verlassen?” zeigen und damit Zeit für den Server-Request gewinnen.
Dazu auch von mir eine Frage: mit dem "beforeunload"-Event kann ich die Meldung anzeigen und z.B. das Speicherskript ausführen. In meinem Fall möchte ich, wenn der Benutzer die Seite vorzeitig verlässt, die von ihm gemachten Eingaben (konkret Platzreservierungen) löschen. In diesem Fall müsste der Löschbefehl ja erst nach dem Klick auf "Wirklich verlassen..." aufgerufen werden. Mit "onunload" ist mir das leider nicht gelungen. Gibt es da eine Möglichkeit? Ich habe es als Workaround mit einem Cronjob gelöst, der nicht abgeschlossene Reservierungen nach einer Weile entfernt.
Vielen Dank,
Grüße Basti-
Hallo,
In meinem Fall möchte ich, wenn der Benutzer die Seite vorzeitig verlässt, die von ihm gemachten Eingaben (konkret Platzreservierungen) löschen. … Gibt es da eine Möglichkeit?
Nein. HTTP ist statuslos, es gibt keine Möglichkeit, eine »Session« ordnungsgemäß zu beenden. Hier kann letztlich nur mit Timeouts gearbeitet werden.
Ich habe es als Workaround mit einem Cronjob gelöst, der nicht abgeschlossene Reservierungen nach einer Weile entfernt.
Das ist die einzige zuverlässige Möglichkeit. Wobei man den Timeout klein halten kann, wenn der Client im Hintergrund pollt und dem Server meldet, dass der Tab noch geöffnet ist (z.B. während der Kunde seine Kreditkartendaten sucht).
Ich würde beim beforeunload einen Request senden, der den Timeout auf ein paar Minuten setzt. Wenn die Seite verlassen wird, dann wird die Session schnell durch einen Cronjob beendet. Gleichzeitig sollte im beforeunload das Polling (neu) gestartet werden. Wenn der Nutzer nämlich auf der Seite bleibt, können weitere Requests gemacht werden, die den Timeout wieder hochsetzen.
Mathias
-
Hallo,
Ich würde beim beforeunload einen Request senden, der den Timeout auf ein paar Minuten setzt. Wenn die Seite verlassen wird, dann wird die Session schnell durch einen Cronjob beendet.
So in der Art mache ich es bereits, vielen Dank für die Hinweise!
Grüße Basti
-
Hello,
Ich würde beim beforeunload einen Request senden, der den Timeout auf ein paar Minuten setzt. Wenn die Seite verlassen wird, dann wird die Session schnell durch einen Cronjob beendet. Gleichzeitig sollte im beforeunload das Polling (neu) gestartet werden. Wenn der Nutzer nämlich auf der Seite bleibt, können weitere Requests gemacht werden, die den Timeout wieder hochsetzen.
Man muss aber nicht die Session beeenden, nur weil der User "die Seite" vorzeitig verlässt.
Erstmal sollten wir uns darüber einig sein, ob damit "die Domain" gemeint ist, oder ob nur eine andere "Seite" innerhalb des Domainangebotes aufgerufen wurde.Aber auch, wenn der User das Domainangebot (erstmal) nicht weiter in Anspruch nimmt, muss man nicht gleich die Session wegschmeißen. Man verklickt scih schon mal und freut sich dann 10 Sekunden später meistens, wenn man wieder dort aufsetzen kann, wo man stand.
Das Problem liegt ganz wo anders:
Wenn für einen vollständigen Buchungsvorgang umfangreiche Änderungen in der DB oder im Dateisystem zu erledigen sind, sollte man die zusammengehörigen Aktionen immer erst in der Session speichern und dann erst auf "Bestätigen" buchen. Für die Durchführung des Buchungsvorganges, der dann aus mehreren Statements usw. bestehen kann, sollte man den User-Abort ausschließen. Wenn der Browser zugeklappt wird, muss das angestoßene Script also noch zuende laufen.
Ein Abort würde nämlich bei den meisten Scriptsprachen im Backend dazu führen, dass das Script auch sofort beendet wird und dadurch "halbe Buchungen" entstehen können. Damit ist die Datenbasis dann inkonsistent geworden.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ein Abort würde nämlich bei den meisten Scriptsprachen im Backend dazu führen, dass das Script auch sofort beendet wird und dadurch "halbe Buchungen" entstehen können. Damit ist die Datenbasis dann inkonsistent geworden.
Es gibt eine Vielzahl an Gründen, warum etwas schief laufen kann. Dem begegnet man mit Transaktionen und gut ist.
-
Hello,
Ein Abort würde nämlich bei den meisten Scriptsprachen im Backend dazu führen, dass das Script auch sofort beendet wird und dadurch "halbe Buchungen" entstehen können. Damit ist die Datenbasis dann inkonsistent geworden.
Es gibt eine Vielzahl an Gründen, warum etwas schief laufen kann. Dem begegnet man mit Transaktionen und gut ist.
Stimmt. Eine Transaktion kann man ggf. für das (Multi-)Statement in der Datenbank benutzen.
Für den gesamten Buchungsvorgang per HTTP/s, der sich auch über mehrere Roundturns erstrecken kann habe ich das noch nicht gesehen. Hast Du da einen Link für mich?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Stimmt. Eine Transaktion kann man ggf. für das (Multi-)Statement in der Datenbank benutzen.
Für den gesamten Buchungsvorgang per HTTP/s, der sich auch über mehrere Roundturns erstrecken kann habe ich das noch nicht gesehen. Hast Du da einen Link für mich?
Jaja, ist gut. Dreh es dir, wie es Dir passt und fühl dich gut beim letzten Wort haben. Viel Spass damit!
-
Hello,
Stimmt. Eine Transaktion kann man ggf. für das (Multi-)Statement in der Datenbank benutzen.
Für den gesamten Buchungsvorgang per HTTP/s, der sich auch über mehrere Roundturns erstrecken kann habe ich das noch nicht gesehen. Hast Du da einen Link für mich?
Jaja, ist gut. Dreh es dir, wie es Dir passt und fühl dich gut beim letzten Wort haben. Viel Spass damit!
Du musst jetzt aber nicht beleidigt sein, nur weil Du mir nicht zeigen kannst, wie der gesamte Buchungsvorgang per HTTP/s (über mehrere Roundturns verteilt) mittels einer Transaktion gekapselt werden kann. Wir könnten - alternativ - aber gerne mal darüber nachdenken, was zu beachten ist.
Aber gemeinsam Nachdenken ist hier wohl schon lange nicht mehr "best practice"
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Hallo,
Ich würde beim beforeunload einen Request senden, der den Timeout auf ein paar Minuten setzt.
Man muss aber nicht die Session beeenden, nur weil der User "die Seite" vorzeitig verlässt. …
Aber auch, wenn der User das Domainangebot (erstmal) nicht weiter in Anspruch nimmt, muss man nicht gleich die Session wegschmeißen.Es ging hier um Ticket-Reservierungen, nicht um Sessions generell. Da ist es sinnvoll, mit Timeout zu arbeiten, der die Reservierung löst (NICHT notwendig die Session beendet). Sonst ist es sehr einfach möglich, die komplette Site lahmzulegen, indem man Reservierungen erzeugt und somit andere am buchen hindert.
Mathias
-
Hello,
Ich würde beim beforeunload einen Request senden, der den Timeout auf ein paar Minuten setzt.
Man muss aber nicht die Session beeenden, nur weil der User "die Seite" vorzeitig verlässt. …
Aber auch, wenn der User das Domainangebot (erstmal) nicht weiter in Anspruch nimmt, muss man nicht gleich die Session wegschmeißen.Es ging hier um Ticket-Reservierungen, nicht um Sessions generell. Da ist es sinnvoll, mit Timeout zu arbeiten, der die Reservierung löst (NICHT notwendig die Session beendet). Sonst ist es sehr einfach möglich, die komplette Site lahmzulegen, indem man Reservierungen erzeugt und somit andere am buchen hindert.
Ich muss zugeben, dass ich Euch jetzt nicht folgen kann. Das Ticket wird doch nicht schon beim Erst-Request der Ressource gebucht, oder?
Ich stelle mir das so vor, dass ich erstmal eine übersicht bekomme, welche Tickets noch vorhanden sind. Und wenn ich dann alles ausgefüllt habe, klicke ich ganz zum Schluss auf "Buchen" und entweder klappt es dann, oder jemand anders war zwischendurch schneller. Dann bekomme ich das eben als Meldung und die neue Übersicht der noch vorhandenen Plätze. Da muss ich dann nur noch schnell (Häkchen setzen und *) Klicken. Meine Stammdaten liegen ja schon vor vom ersten Roundturn.
*) Häkchen (Checkbox) setzen, damit man auch vier Plätze auf einmal reservieren kann.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ich stelle mir das so vor, dass ich erstmal eine übersicht bekomme, welche Tickets noch vorhanden sind. Und wenn ich dann alles ausgefüllt habe, klicke ich ganz zum Schluss auf "Buchen" und entweder klappt es dann, oder jemand anders war zwischendurch schneller.
Nein, so funktioniert Ticket- und Platzreservierung eben nicht. Wie basti_p auch schreibt, der Platz wird beim Starten des Buchungsvorgangs erst einmal geblockt. Es kann also kein anderer den »zwischendurch schneller« sein! Das wäre sehr frustrierend für den Kunden.
Mathias
-
Hello,
Ich stelle mir das so vor, dass ich erstmal eine übersicht bekomme, welche Tickets noch vorhanden sind. Und wenn ich dann alles ausgefüllt habe, klicke ich ganz zum Schluss auf "Buchen" und entweder klappt es dann, oder jemand anders war zwischendurch schneller.
Nein, so funktioniert Ticket- und Platzreservierung eben nicht. Wie basti_p auch schreibt, der Platz wird beim Starten des Buchungsvorgangs erst einmal geblockt. Es kann also kein anderer den »zwischendurch schneller« sein! Das wäre sehr frustrierend für den Kunden.
Bevor er an die Platzübersicht kommt, muss er seine Stammdaten eigeben.
Und schon kann der restlcihe Buchungsvorgang in wenigen Sekunden erledigt werden.Ich möchte Dich mal vor einem eBay-Screen sehen, auf dem Du dein Wunschprodukt zum Gebot anzeigen lässt. Da suchst Du doch auch nicht erst Deine Lieferadresse oder Deine Kreditkartendaten, bevor Du auf das ultimative "Gebot bestätigen" klickst.
Eine vernünftige Planung des Programmes erspart viel Kummer. Das akzeptieren auch die Kunden, da ja für alle dieselben Regeln gelten.
Natürlich bis auf diejenigen, die gleicher sind, als Du und ich. Die haben schon immer gewonnen ...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Ich möchte Dich mal vor einem eBay-Screen sehen, auf dem Du dein Wunschprodukt zum Gebot anzeigen lässt. Da suchst Du doch auch nicht erst Deine Lieferadresse oder Deine Kreditkartendaten, bevor Du auf das ultimative "Gebot bestätigen" klickst.
eBay ist kein Ticket- oder Platzreservierungssystem. Soviel zu diesem unsinnigen Vergleich.
Eine vernünftige Planung des Programmes erspart viel Kummer.
Ja, dir. Und bereitet deinen Kunden Kummer.
Ersthaft, es gibt in diesem Bereich etablierte Best Practices, und die funktionieren nicht so, wie du es hier schilderst. Es gibt auch keinen Grund, davon abzuweichen.
Mathias
-
Hello,
Ja, dir. Und bereitet deinen Kunden Kummer.
Ersthaft, es gibt in diesem Bereich etablierte Best Practices, und die funktionieren nicht so, wie du es hier schilderst. Es gibt auch keinen Grund, davon abzuweichen.
Schön, dass wir mal darüber gesprochen haben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo!
Lass mal bitte die Kirche im Dorf. Niemand hat dir hier den Mund verboten. Du kannst meinetwegen gerne über Gott und die Welt sinnieren und es hier posten. Ich sehe lediglich keinen Sinn darin, über neue technische Lösungen zu diskutieren, die Anforderungen verleugnen, die bekannte und bewährte Lösungen erfüllen.
Eine Software, die die Nutzerbedürfnisse hinten anstellt, würde ich nicht als »vernünftig geplant« zu bezeichnen. Bei solchen Vorhaben geht es hauptsächlich um Erwartungskonformität und User Experience. Freilich ist technische Einfachheit und Machbarkeit ein weiteres Kriterium, aber man sollte nicht vergessen, wo die Prioritäten liegen.
Mathias
-
-
-
Hi,
Bevor er an die Platzübersicht kommt, muss er seine Stammdaten eigeben.
Und dann hat der potentielle Kunde viele Daten eingegeben, nur um am Schluß festzustellen, daß gar keine Plätze mehr frei sind, weil jemand anderes schneller war und während der Dateneingabe die letzten Plätze weggeschnappt hat, er also seine Daten dem Veranstalter gar nicht geben will, weil er dort ja gar nichts mehr kaufen kann/will.
Oft ist es ja auch so, daß die Plätze unterschiedlich kosten - der Kunde muß also zuerst die noch vorhandenen Plätze sehen, um dann anhand des Preises zu entscheiden, ob er überhaupt Karten kaufen will (könnte ja sein, daß nur noch Karten verfügbar sind, die ihm zu teuer sind ...).
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Hello,
Bevor er an die Platzübersicht kommt, muss er seine Stammdaten eigeben.
Und dann hat der potentielle Kunde viele Daten eingegeben, nur um am Schluß festzustellen, daß gar keine Plätze mehr frei sind, weil jemand anderes schneller war und während der Dateneingabe die letzten Plätze weggeschnappt hat, er also seine Daten dem Veranstalter gar nicht geben will, weil er dort ja gar nichts mehr kaufen kann/will.
Das ist eine unbegründete Angst. Der Anbieter verliert dabei nichts. Ob er nun den einen Kunden oder den anderen verprellen muss, ist für ihn unerheblich. Aber ein System künstlich langsam zu machen um die Convenience vermeintlich zu steigern, das ist dumm.
Der Kunde, der kaufen will, muss sich darüber im Klaren sein, dass seine Daten dazu erfasst werden müssen. Derjenige, der erstmal nur anonym (nur NSA & Freinds wissen Bescheid) gucken will, muss sich darüber klar sein, dass die Anzeige des Ticketanbieters absolut unverbindlich ist, also nur ein "Invitatio ad Offerendum" darstellt.
Wer es ernst meint, ist sowieso bei seinem Ticket-Anbieter registriert, weil er dann auch Sonderkontingente, Backstage-Pässe und ähnliches angeboten bekommt.
Oft ist es ja auch so, daß die Plätze unterschiedlich kosten - der Kunde muß also zuerst die noch vorhandenen Plätze sehen, um dann anhand des Preises zu entscheiden, ob er überhaupt Karten kaufen will (könnte ja sein, daß nur noch Karten verfügbar sind, die ihm zu teuer sind ...).
Das ist ja kein Problem. Wenn er registriert ist, braucht er nur auf den Platz zu zeigen, einmal zu klicken, und der Platz ist für ihn reserviert.
Wenn das Ticket-System schlau ist, fragt es vorher: "Wieviel zusammenhängende Plätze wünschest Du, oh mein König?". Und wenn der Kunde dann auf _einen_ einzelnen Platz klickt, werden ihm sofort (für 15 Sekunden) x nebeneinander oder an einem Tisch befindliche Plätze reserviert und mit Endpreisanzeige angeboten. Er muss nun nur noch auf "Ja" oder "nein" klicken, und das Geschäft kommt zustande.
Wenn hier eine Competition (aus der Race Condition) zustande kam, dann bekommen ggf. einige der Konkurrenten die Antwort: Achtung, da war Einer schneller, aber genau eine Reihe davor/dahinter/daneben haben wir mal prophilaktisch ein Angebot für Dich aufbereitet und für 15 Sekunden reserviert.
Man muss doch nur das Verfahren im Vorfeld in wenigen Sätzen und Bildern verständlich erklären.
Aber ich weiß von einem Freund, der ein wirklich großes Veranstaltungszentrum betreut, dass er mit seiner "scheiß Ticketsoftware" überhaupt nicht zufrieden ist. Der möchte am liebsten eine "Back to the Roots"-Lösung (also ohne JavaScript und Schickimicki) haben. Die bietet nur keiner an, weil alle Rumprogrammierer denken "Best Practice" ist das, was Alle machen... Jeder schreibt vom Anderen ab. Wenn die Technik siebzehn Neuerungen bietet, muss man die auch alle möglichst gleichzeitig verwenden, sonst ist man ja nicht cool.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Wenn das Ticket-System schlau ist, fragt es vorher: "Wieviel zusammenhängende Plätze wünschest Du, oh mein König?". Und wenn der Kunde dann auf _einen_ einzelnen Platz klickt, werden ihm sofort (für 15 Sekunden) x nebeneinander oder an einem Tisch befindliche Plätze reserviert und mit Endpreisanzeige angeboten. Er muss nun nur noch auf "Ja" oder "nein" klicken, und das Geschäft kommt zustande.
Ich vergaß: an dieser Stelle finde ich JavaScript ganz praktisch. Da kann nämlich der Client schon X Plätze ausgucken und markieren und rechnen und anzeigen. Und wenn der Kunde jetzt klickt und Angebot und Annahme stimmen noch überein, ist das Geschäft sofort perfekt, sonst muss halt nochmal eine Runde "Sorry, da war doch jemand schneller, aber hier das Alternativ-Angebot" versucht werden.
Man KANN Ticket-Systeme ziemlich schnell machen. Man muss nur jeden Quatsch weglassen, der niemandem wirklich etwas nützt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Der Anbieter verliert dabei nichts. Ob er nun den einen Kunden oder den anderen verprellen muss, ist für ihn unerheblich. Aber ein System künstlich langsam zu machen um die Convenience vermeintlich zu steigern, das ist dumm.
Mit der Attitüde bringt man sicher Produkte auf den Markt, die gut bei den Kunden ankommen. NICHT.
Es hat schon seinen Grund, warum bestehende Ticketsysteme so arbeiten. Warum sie technische Komplexität in Kauf nehmen, um Benutzerfreundlichkeit zu erreichen. Weil es ein Workflow ist, den User gewöhnt sind. Weil es ein Komfort ist, den User fordern und erwarten. Weil es seriös ist, NACH dem Auswahl der Ware die Zahlungsdaten einzugeben. Weil die Zahlungssart erst dann bestimmt werden kann. Weil die Zahlung oft über externe Provider wie Stripe oder PayPal erfolgt, die Summe dafür feststehen muss und die Zahlungsdaten aus Datenschutzgründen nicht selbst erfasst werden (ich wiederhole mich).
Aber nein, Tom steht darüber und meint, dass das, was die großen Sites in diesem Bereich machen, »dumm« sei, dass man ruhig mal den einen oder anderen Kunden verprellen müsse…
Der Kunde, der kaufen will, muss sich darüber im Klaren sein, dass seine Daten dazu erfasst werden müssen.
Ja. NACHDEM ich die Waren/Produkte ausgewählt habe und den Preis im Warenkorb sehe! Dann drücke ich auf »Jetzt bezahlen«. So funktionieren Online-Shops. Aus Gründen.
Derjenige, der erstmal nur anonym (nur NSA & Freinds wissen Bescheid) gucken will, muss sich darüber klar sein, dass die Anzeige des Ticketanbieters absolut unverbindlich ist, also nur ein "Invitatio ad Offerendum" darstellt.
Das kann man so umsetzen, aber benutzerfreundlich ist das nicht. Die meisten werden erst einmal anonym sein, vielleicht sogar Erstkunden. Die meisten können also nur unverbindlich Tickts/Plätze auswählen, bis die Zahlung durch ist. Das ist eine grottige User Experience, das zeigt den Nutzern den Mittelfinger.
Wer es ernst meint, ist sowieso bei seinem Ticket-Anbieter registriert, weil er dann auch Sonderkontingente, Backstage-Pässe und ähnliches angeboten bekommt.
Neukunden, die noch nicht registriert sind, meinen es auch ernst!
Wenn hier eine Competition (aus der Race Condition) zustande kam, dann bekommen ggf. einige der Konkurrenten die Antwort: Achtung, da war Einer schneller, aber genau eine Reihe davor/dahinter/daneben haben wir mal prophilaktisch ein Angebot für Dich aufbereitet und für 15 Sekunden reserviert.
Diese Logik umzusetzen ist viel komplizierter als einfach die Plätze temporär zu blocken, sobald sie der User auswählt. Dass es frustrierend für den Nutzer ist, habe ich bereits gesgt.
Wenn die Technik siebzehn Neuerungen bietet, muss man die auch alle möglichst gleichzeitig verwenden, sonst ist man ja nicht cool.
Ich habe den Eindruck, dass du nicht verstehst, worum es in dieser Diskussion geht. Es ist IMMER Best Practice, im Sinne des Nutzers, im Sinne von Bedienkomfort und Usability zu handeln. Technik ist nur ein Mittel zum Zweck und muss möglich machen, was aus Produktsicht sinnvoll ist.
Mathias
-
Hallo
… Es ist IMMER Best Practice, im Sinne des Nutzers, im Sinne von Bedienkomfort und Usability zu handeln. Technik ist nur ein Mittel zum Zweck und muss möglich machen, was aus Produktsicht sinnvoll ist.
Schon alleine dafür ein „fachlich hilfreich“.
Es scheint nicht jedem bewusst zu sein, dass das, was wir machen, nicht einfach nur auf dem einfachsten Wege gemacht werden soll (damit es erledigt ist und funktioniert), sondern so, dass es für das Zielpublikum in jeglicher Hinsicht *benutzbar* ist. Das ist nicht immer einfach und manchmal muss man x mal darüber sinnieren (lassen), aber es ist das Ziel.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3-
Hallo,
Usability ist – zumindest in dem fraglichen Bereich – auch nur ein Mittel zum Zweck.
Wenn ich Tickets verkaufe, will ich, dass Leute den Bestellvorgang erfolgreich abschließen und mit der UX zufrieden sind. Warum? Weil mir das Geld bringt. Weil ich so Kunden gewinne, die mir vertrauen.
Das ist einfach eine wirtschaftliche Kosten-Nutzen-Rechnung. Wie viel Geld investiere ich, um ein komplexes technisches System aufzusetzen und zu warten? Wie viel mehr Umsätze und zufriedene Kunden bringt mir das langfristig?
Die besagten Ticketsysteme arbeiten nicht so, weil sie gerne overengineeren oder Benutzer über alles lieben, sondern weil sie so mehr Tickets verkaufen. Erfahrungsgemäß. Sonst hätten sie die technische Komplexität schnell wieder eingestampft, denn die kostet eben Geld.
Mathias
-
Hallo
Die besagten Ticketsysteme arbeiten nicht so, weil sie gerne overengineeren oder Benutzer über alles lieben, sondern weil sie so mehr Tickets verkaufen. Erfahrungsgemäß. Sonst hätten sie die technische Komplexität schnell wieder eingestampft, denn die kostet eben Geld.
Es ist auch mir klar, dass die Betreiber (gerade) kommerzieller Angebote das nicht aus purer Menschenliebe bereitstellen und dass Optimierungen (auch ökonomische) Grenzen haben. Dein Beitrag fasste nur so schön zusammen, warum ich mir beim Lesen des Threads gelegentlich an den Kopf fasste.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
Veranstaltungsdatenbank Vdb 0.3-
Es ist auch mir klar, dass die Betreiber (gerade) kommerzieller Angebote das nicht aus purer Menschenliebe bereitstellen und dass Optimierungen (auch ökonomische) Grenzen haben.
War auch weniger an dich gerichtet und war nicht als Korrektur gemeint (falls es so verstanden wurde) – ich wollte nur ergänzen, dass das eine weitere wichtige Dimension ist.
Grüße
Mathias
-
-
-
-
-
-
-
-
-
-
-
Hallo,
in meinem Fall handelt es sich um ein Tischreservierungssystem für Veranstaltungen.
Sobald ein User einen Tisch anklickt, öffnet sich der Dialog mit den Optionen für diesen Tisch.
Gleichzeitig wird eine Buchung mit Status "pending" angelegt - in der DB, weil der Tisch zu diesem Zeitpunkt schon als reserviert gilt. Ein Ajaxrequest pollt regelmäßig den Server und aktualisiert die Kennzeichnung der Tische als frei/belegt. Der User hat 15 Minuten Zeit, die Buchung abzuschließen. Nach dieser Zeit wird er über die Rücksetzung seiner Eingaben informiert und die Buchung gelöscht.Eine Speicherung der Buchung nur in der Session kommt demzufolge nicht in Frage (weil ja alle, auch noch nicht abgeschlossenen Buchungen für die Anzeigeaktualisierung sofort verfügbar sein müssen).
Das Aufräumscript sucht permanent nach Buchungen, deren Status auf "pending" steht und deren letzter Ajax-Poll länger als 5 Minuten her ist und löscht diese.
Grüße Basti
-
Hello Basti,
ich hatte Dich also schon richtig verstanden.
Das Aufräumscript sucht permanent nach Buchungen, deren Status auf "pending" steht und deren letzter Ajax-Poll länger als 5 Minuten her ist und löscht diese.
Aber ein Aufräumscript benötigst Du dann nicht jedes Mal. Das reicht, wenn man das einmal am Tag laufen lässt.
Der Tisch ist eben "pending" solange er maximal darf (Aktueller_Timestamp - Timestamp_letzter_Buchungsschritt) oder bis die Buchung tatsächlich bestätigt wurde.
Und zusätzlich hast Du dann noch den Timestamp_Buchungsstart, um - wie Du es schon beschreibst - die Blockierer auszufiltern. Du bnötigst also zwei (drei) Timestamps für den User in der Datenbank (Datensatz ist über die Session unique indiziert):
- Buchungsstart -> DB
- TS letzter Request der Buchung -> DB, Zeit zwischen zwei Roundturns zb. 90 Sek)
- TS aktuelle Zeit -> System
- TS Buchungsbestätigung -> DB
und zwei Zeitbegrenzungen
- Maximale Gesamtdauer für eine Buchung
- Maximale Dauer zwischen zwei Buchungsschritten.
Die Einstellung session.gc_maxlifetime muss auf jeden Fall länger ssein, als die maximale Dauer zwischen zwei Buchungsschritten.
Wenn man die Zeiten passend wählt, ist Ajax also auch nicht unbedingt notwendig. 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.
Durch passende Abfragen kannst Du normalerweise alles filtern, was Du brauchst.
Empfehlenswert ist dann noch ein Button "Verwerfen" im Formular, dass den Datensatz mit der laufenden Session ungültig macht (z.B. durch Eintrag eines bestimmten Textes+Timestamp in das Sessionfeld) udn dem user ggf. eine neue Sessionnummer gibt. Das spielt dann aber auch ins Anmeldesystem, falls Du feste User-Accounts hast.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Wenn man die Zeiten passend wählt, ist Ajax also auch nicht unbedingt notwendig. 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.
Das Ajax-Poll sorgt ja für die Aktualisierung der Ansicht im Browser (Tische werden als gebucht/frei gekennzeichnet und mit dem entsprechenden Eventhandler ausgestattet). Das Aufräumen erledigt das Skript quasi nebenbei - aber Du hast natürlich recht, das Aufräumen kann in einem größeren Intervall erfolgen; das werde ich ändern.
Grüße Basti
-
Hallo,
ich hatte Dich also schon richtig verstanden.
Hast du offensichtlich nicht.
Das Aufräumscript sucht permanent nach Buchungen, deren Status auf "pending" steht und deren letzter Ajax-Poll länger als 5 Minuten her ist und löscht diese.
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! Sonst kann ich, indem ich hunderte Sessions öffne und Tische blocke, das gesamte Buchungsverfahren lahmlegen. Bei Sitzplätzen in Konzerten oder Tickets generell ist das sehr wichtig, da meistens ein Andrang zum Start des Ticketverkaufs stattfindet. Wenn tausende versuchen, ein Ticket zu bekommen, ist es wichtig, dass die Blockierung schnell wieder aufgehoben wird, damit andere zum Zug kommen.
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 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.Mathias
-
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=1487954Ein "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
-
Hallo,
Und für den Timeout benötigt man kein "Aufräumscript", sondern nur eine entsprechend formulierte Abfrage an die Datenbank.
Das kann man so lösen, ja. Voraussetzung ist, dass man die Logik in einer Abfrage unterbringen kann. Die Logik muss man dann aber (verneint) verdoppeln, nämlich im Aufräumscript.
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.
Das ist dann eine Frage der Performance-Optimierung, und auch hier gilt »do not optimize prematurely«.
Das Szenario habe ich schon beschrieben: Nutzer sucht seine Kreditkarten heraus.
Das soll er gefälligst vorher tun.
Du weißt anscheinend nicht, wie die meisten Shops funktionieren. Die Zahlungsdaten gehören nicht zu den Stammdaten, sondern werden erst nach der Auswahl der Produkte eingegeben – also hier nach der Blockierung der Karten bzw. Sitze. Das liegt daran, dass erst dann der Preis berechnet werden kann, die die möglichen Zahlungsarten einschränken kann. Oftmals erfolgt die Bezahlung durch Payment-Provider erfolgt (z.B. Stripe, Paymill). Dann will man die Zahlungsdaten selbst gar nicht speichern, denn das hat massive Implikationen für Sicherheit und Datenschutz.
- 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.
Doch, sollte es. Sofort, im Moment der Auswahl. So machen die meisten Buchungssysteme. Aus Kundenfreundlichkeit.
Mathias
- mittels JavaScript (scheint ja aktiv zu sein *höhö*) kann er jetzt mehrere
-
-
-
-
-
-
-