Zum Inhalt springen

Asynchrones Dilemma

Asynchrone Requests machen das A in AJAX aus und bieten viel Raum für interessante Betrachtungen. Hier geht es heute um das Problem, das veraltete Anfragen sauber erkannt oder alternativ ein hohe Anzahl von Antworten schnell verteilt werden sollen. Anhand einer Abstraktion werde ich den ersten Punkt beispielhaft beschreiben.

Aktuell bin ich in einem Projekt eingebunden, das sehr viel mit asynchronen Aufrufen arbeitet. Da es sich um eine Webapplikation handelt, ist dies nicht ganz so verwunderlich. Aber zuerst eine kurze Beschreibung des Problems.

Der Anwender kann durch eine Aktion einen Request (A1) auslösen, der – sobald die Antwort vom Server verarbeitet wurde – einen zweiten Request (A2) auslöst. Dessen Antwort kann unter Umständen beliebig viele weitere Requests (A1′) starten, die dem ersten ähneln. Wobei „beliebig“ berechnet werden kann und einen maximal Wert hat.
Währen der Verarbeitung der A-Requests- und Response-Daten kann der Benutzer weitere Requests auslösen. Bspw. B1, C1 und D1. Das System verarbeitet diese neuen Requests wie den ersten und wir haben eine wahre Flut von Requests.

Das beim Auslösen von Request B1 die Komponente, die alles verwaltet partiell zurückgesetzt wird, hat man das Problem, das die Antwort von A2 nach dem zurücksetzen eingehen kann und damit zu einem inkonsistenten Zustand führen kann.

Der anfänglich theoretische Zustände konnte bei entsprechenden Benutzung erreicht werden. Somit war die Anwendung an dieser Stelle nicht robust und musste angepasst werden.

Wir haben uns für das ACT-Pattern entschieden. Also einen Asynchronous Completion Token eingeführt. Das heißt, sobald der Request A1 gefeuert wird, setzen wir einen Token in der Komponente und geben diesen dem Request mit. Alle Antworten und Requests, die aus A1 resultieren, müssen diesen Token mitführen, sonst werden sie verworfen und somit die Verarbeitung abgebrochen.

Löst der Benutzer B1, C1 und/oder D1 aus, wird der Token der Komponente neu gesetzt und somit können veraltete Antworten identifiziert werden. Dadurch haben wir die Komponente immer in einem gültigen Zustand.

Als Token nutzen wir aktuell einen Zeichenkette mit 10 Zeichen, die zufällig aus dem Alphabet (inkl. Groß- und Kleinschreibung) und den Zahlen von 0-9 zusammengesetzt sind. Man kann sich auch andere Tokens vorstellen – bspw zeitbasierte oder Hashwerte über bestimmte Request-Parameter.
Unsere 10 Zeichen-Implementierung werden wir noch ersetzen, denn es nicht sichergestellt ist, dass 2 aufeinanderfolgende Tokens nicht zufällig gleich sind. Dann hätte der Zufallszahlengenerator ein Problem oder es wäre der sprichwörtliche 6er im Lotto – und genau das passiert, wenn man eine solche Implementierung Live schaltet 😉

Published inAllgemein

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close