Mein Reload von heute Morgen. Geplante Vorgangsbearbeitung
Tom
- zu diesem forum
Hello,
mein Doppelpostign durch reload von ehute Morgen hat mir doch nochmal zu Denken gegeben.
Ich habe das Posting ganz normal abgeschickt (Submit)
Dann kam die Antwort: Ihr Posting ist jetzt sichtbar... (o.ä.)
Und dann habe ich in diesem Fesnter mangels Brille nochmal auf Reload geklickt und dann auch ganz in Gdekane das Browser-Popup mit der Frage nach dem nochmaligen Senden der Daten bestätigt.
Es gibt also zwei verschiedene Reload-Probleme?
Eines das durch allzu nervöses Klicken auf den Submitbutton entsteht und das zweite, durch Klicken auf "Reload" im Browserfenster.
Vermeiden könnte man doch aber wahrschinlich beide, wenn man jedem Formular eine eindeutige ID mit auf dem Weg schickt, und die Auswertung davon abhängig macht, dass diese noch nicht bearbeitet wurde. Sehe ich das richtig oder gibt's da 'ne Denklücke?
Wenn nicht, dann wäre das ein Fall für meine "automatisierte Vorgangsbearbeitung", die im Entstehen ist.
Grüße
Tom
Hi Tom,
Vermeiden könnte man doch aber wahrschinlich beide, wenn man jedem Formular eine eindeutige ID mit auf dem Weg schickt, und die Auswertung davon abhängig macht, dass diese noch nicht bearbeitet wurde.
Es gibt eine derartige ID bereits, bei mir grade '<input type="hidden" name="unid" value="zz0Y4yXZ13YZ0">'. Die soll genau dieses Problem verhindern.
Gruss,
Carsten
Hello Carsten,
Vermeiden könnte man doch aber wahrscheinlich beide, wenn man jedem Formular eine eindeutige ID mit auf dem Weg schickt, und die Auswertung davon abhängig macht, dass diese noch nicht bearbeitet wurde.
Es gibt eine derartige ID bereits, bei mir grade '<input type="hidden" name="unid" value="zz0Y4yXZ13YZ0">'. Die soll genau dieses Problem verhindern.
Ja, danke. Das habe ich beim Nachschauen eben auch gesehen, dass da wohl 'was vorgesehen ist. Ist das System nun noch nicht implementiert, oder gibt's da auch Lücken?
Rein von der Logik her müsste man doch denken, dass das nicht passieren kann, wenn alle Vorgänge vernünftig serialisiert werden.
--> Das ist ein neues Problem...
Allerdings lagen zwischen meinen beiden Postings heute Morgen einige Hundert Sekunden (ca. 15'*60"/' -> 900")
Das zweite Posting ist also eindeutig nach dem ersten eingegangen.
Habe ich hier nun noch irgendwas übersehen, was mein Modell für die geplante Applikation zum Einsturz bringt, oder ist hier im Forum nur irgendwas noch nicht istalliert? Ich will das Forum nihn nicht als Testplatz missbrauchen. Wäre also nett, wenn die Geister da mal aus der Schule plaudern könnten.
Grüße
Tom
Hallo Tom,
Es gibt eine derartige ID bereits, bei mir
grade '<input type="hidden" name="unid"
value="zz0Y4yXZ13YZ0">'. Die soll genau
dieses Problem verhindern.Ja, danke. Das habe ich beim Nachschauen eben
auch gesehen, dass da wohl 'was vorgesehen ist.
Ist das System nun noch nicht implementiert,
oder gibt's da auch Lücken?
Es gibt eine Luecke, oder besser gesagt, eine
Uebereinkunft. Die Threads werden in einer Liste
gespeichert, und um nicht die komplette Liste
durchlaufen zu muessen (kostet viel Performance!),
habe ich einfach definiert, dass nur der letzte
eingetragene Thread auf eine bereits vorhandene
Unique-ID ueberprueft wird. Bei dir war das jetzt
so, dass inzwischen ein neuer Thread gepostet
wurde, mit einer anderen Unique-ID. Dadurch wurde
nicht der richtige Thread ueberprueft, so dass das
Doppelposting nicht als solches erkannt wurde. Das
ist halt so ein 80-20-Fall. In 80% der Faelle
gehts gut, in 20% hat man ein Doppelposting. Ich
wuerde die Prozentzahlen eher auf 99% und 1%
druecken, aber trotzdem kommt es vor. Das ist der
Preis, den ich dafuer zahle, dass ich mir das
durchackern der Liste spare ;)
Gruesse,
CK
Hello Christian,
hab Dank für die Erklärung.
Dann kann ich ja weiterbasteln. Ich nehm wohl ne DB-Tabelle dafür...
Grüße
Tom
Hallo Tom,
Dann kann ich ja weiterbasteln. Ich nehm wohl ne
DB-Tabelle dafür...
Ich persoenlich werde jetzt in diesem Forum die
Unique-IDs wohl zukuenftig in einem AVL-Baum halten.
Damit kann das Problem dann nicht mehr auftreten.
Gruesse,
CK