© Liashko/Shutterstock.com
Asynchrone Requests und Race Conditions in GWT

Wider den Schluckauf


Für die Kommunikation zwischen Server und Client verwendet Google Web Toolkit (GWT) asynchrone Requests [1]. Hierbei sendet der Client eine Anfrage an den Server und erhält die Antwort zeitlich versetzt, wodurch für den Nutzer der Webseite ein Weiterarbeiten ohne Blockieren des Workflows möglich ist – ein Muss für die heutigen Erwartungen an Usability.

Video: Google Web Toolkit (GWT) - Einführung

Bei Applikationen mit größeren, komplexen User Interfaces kann dies jedoch zu Problemen in Form von Race Conditions führen. Um damit in Hinblick auf Codequalität, korrekter Funktionalität und konkreter Situation sinnvoll umzugehen, gibt es mehrere Alternativen.

Ausgangssituation

Die Spezifikation für unser Beispiel: Eine zu erstellende Webseite beinhaltet eine Listbox, die mit Werten aus einer Datenbank befüllt werden soll, sowie einen Button, der das Hinzufügen von neuen Werten ermöglichen soll. Dieser Button soll nicht angezeigt werden, wenn sich in der Datenbank bereits fünf oder mehr Werte befinden. Außerdem soll der Button unabhängig von der Anzahl der Werte in der Listbox auch dann nicht angezeigt werden, wenn eine zusätzliche Datenbankanfrage über die Rechte des Benutzers negativ ausfällt. Sichtbar ist der Button daher lediglich dann, wenn sich sowohl weniger als fünf Werte in der Listbox befinden als auch die notwendigen Rechte vorhanden sind.

In der zu unserem Beispiel zugehörigen Serviceklasse auf der Serverseite gibt es zwei Methoden: fillListbox() und hasAddRights(). Dieses reduzierte Beispiel soll die grundsätzliche Problematik zeigen, dass in einem komplexen UI einander widersprechende Wünsche betreffend der Behandlung einzelner Kontrollelemente existieren. Eine gute Diskussion zu diesem Thema findet sich unter [2].

Ein erster Versuch

Die erste, naive Umsetzung der gewünschten Funktionalität auf Clientseite zeigt Listing 1. Auf den ersten Blick kann diese Implementierung für einen nicht an asynchrone Requests gewöhnten Entwickler die gewünschte Funktionalität liefern. Tatsächlich erhält der Client die Ergebnisse der beiden Abfragen nur zufällig in der Reihenfolge, die zur korrekten Anzeige des UI führt. Unter Umständen kehrt nämlich der zweite Request zuerst zurück, sodass die Variable tooManyValues (noch) auf true steht. Obwohl das der Fall sein sollte, wird der Button dann auch bei entsprechenden Rechten nicht angezeigt.

Wie bei jedem Auftreten von Race Conditions ist dabei besonders unangenehm, dass das Verhalten nicht deterministisch ist. Un...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang