Wenn die Leitung reißt: Wie unsere Anwendung sich selbst zurückholt

Es gibt einen Moment, den jeder kennt, der mit einer Anwendung arbeitet, die mit einem Server spricht. Man tippt, klickt, speichert — und plötzlich passiert nichts mehr. Irgendwo im Hintergrund ist die Verbindung weg. Vielleicht wurde der Server aktualisiert, vielleicht hat das Netz gehustet. Und dann kommt der Satz, den man in Handbüchern viel zu oft liest: Bitte starten Sie die Anwendung neu.

Wir haben uns diesen Satz genauer angesehen und beschlossen, dass er in unserer Immobilienverwaltung nichts zu suchen hat.

Was beim Neustart eines Servers wirklich passiert

Aus Sicht des Arbeitsplatzes ist ein Serverneustart ein kleiner Weltuntergang. Nicht, weil Daten verloren gingen — die liegen sicher. Sondern weil drei Dinge auf einmal ihre Gültigkeit verlieren.

Das erste ist die Anmeldung. Wer sich anmeldet, bekommt einen Ausweis für die Sitzung, und mit diesem Ausweis wird jede weitere Anfrage unterschrieben. Startet der Server neu, kennt er die ausgestellten Ausweise nicht mehr. Der Arbeitsplatz hält also einen Ausweis in der Hand, den niemand mehr anerkennt — und er merkt es erst, wenn er ihn vorzeigt.

Das zweite sind die laufenden Ladevorgänge. Ein Arbeitsplatz mit mehreren offenen Dokumenten fragt ständig Daten nach. Fällt der Server aus, laufen diese Anfragen alle gleichzeitig ins Leere — und jede einzelne würde für sich genommen versuchen, das Problem zu lösen. Zwanzig Ansichten, zwanzig Fehlermeldungen, zwanzig Anmeldeversuche.

Das dritte ist die Benachrichtigung. Unsere Anwendung wartet nicht darauf, dass jemand auf „Aktualisieren" drückt: Ändert eine Kollegin etwas, erfährt der eigene Arbeitsplatz das sofort über eine dauerhaft offene Leitung. Genau diese Leitung ist beim Ausfall als Erstes weg.

Der Ausweis, der sich selbst erneuert

Die eigentliche Ursache für den erzwungenen Neustart war banal: Der Ausweis war an mehreren Stellen fest eingebaut. Man hätte ihn nirgends austauschen können, ohne die halbe Anwendung neu aufzubauen — und dabei wären alle offenen Dokumente verloren gegangen.

Also haben wir es umgedreht. Es gibt jetzt genau einen Ort, an dem der aktuelle Ausweis liegt, und jeder Weg zum Server holt ihn sich dort frisch ab, bei jeder einzelnen Anfrage. Der Vorteil zeigt sich in dem Moment, in dem ein neuer Ausweis nötig wird: Er wird eingetragen, und ab der nächsten Anfrage gilt er überall — ohne dass eine geöffnete Liste, ein bearbeitetes Exposé oder ein Dialog auch nur zuckt.

Darauf aufbauend war der Rest fast selbstverständlich. Weist der Server eine Anfrage zurück, weil er die Sitzung nicht mehr kennt, meldet sich die Anwendung im Hintergrund neu an und schickt die Anfrage noch einmal. Der Aufrufer sieht davon nichts.

Ein Detail, auf das wir besonders geachtet haben: Wenn nach einem Neustart zwanzig Anfragen gleichzeitig zurückgewiesen werden, darf das eine Anmeldung auslösen, nicht zwanzig. Die erste erneuert die Sitzung, die übrigen warten kurz und benutzen das Ergebnis mit. Im Protokoll sieht man das schön: viele Zurückweisungen, eine Anmeldung, danach Ruhe.

Warten ist besser als Scheitern

Die zweite Erkenntnis war, dass Fehlschlagen selten die richtige Antwort ist.

Solange der Server nicht antwortet, hat es keinen Sinn, dass zwanzig Ansichten ihre Daten anfordern. Früher hätte jede von ihnen es versucht, wäre gescheitert und hätte eine Fehlermeldung ins Protokoll geschrieben — und die Liste hätte weiter alte Daten gezeigt, ohne dass jemand davon wusste. Heute laden sie schlicht gar nicht erst. Die Anforderung bleibt vorgemerkt und wird eingelöst, sobald der Server wieder da ist. Dann aktualisiert sich alles gemeinsam.

Dasselbe gilt für die dauerhaft offene Benachrichtigungsleitung. Solche Verbindungen versuchen es üblicherweise ein paar Mal und geben dann auf — nur dauert ein Serverneustart eben länger als diese paar Versuche. Das Ergebnis war eine Anwendung, die zwar wieder Daten laden konnte, aber bis zum Programmende nichts mehr mitbekam. Jetzt versucht sie es weiter, mit wachsenden Abständen, so lange die Anwendung läuft.

Ein Dialog, der sich selbst wieder schließt

Bleibt die Frage, was der Mensch vor dem Bildschirm in dieser Zeit sehen soll.

Wir haben uns bewusst gegen eine kleine Anzeige in der Statusleiste entschieden. Eine Anwendung, die halb bedienbar bleibt, verleitet dazu, weiterzuarbeiten — Formulare auszufüllen, Schaltflächen zu drücken, deren Wirkung nirgendwo ankommt. Das ist keine Freundlichkeit, das ist eine Falle.

Stattdessen legt sich ein Fenster über die Anwendung, das erklärt, was los ist, und jede Eingabe auffängt. Es ist kein Fehlerdialog: Es zählt keine Fehlschläge auf, sondern sagt, dass die Verbindung wiederhergestellt wird und die Arbeit dort weitergeht, wo sie unterbrochen wurde. Wer nicht warten will, kann jederzeit einen sofortigen Versuch auslösen, statt dem nächsten automatischen zuzusehen.

Drei Eigenschaften waren uns dabei wichtig:

• Es schließt sich von selbst. Steht die Verbindung wieder, verschwindet das Fenster ohne Zutun — und der Cursor steht noch da, wo er vorher stand.
• Es lässt sich nicht wegklicken. Weder ein versehentliches Escape noch das Schließkreuz führen zurück in eine Anwendung, die ohnehin nichts tun könnte. Wer wirklich aufhören will, beendet sie über die dafür vorgesehene Schaltfläche.
• Es fragt nur, wenn es fragen muss. Wurde in der Zwischenzeit das Passwort geändert, fragt es danach — sonst regelt es alles im Hintergrund.

Und dann kommt alles zurück

Der schönste Teil ist der Moment der Rückkehr, denn dort liegt eine Reihenfolge, die man leicht falsch macht.

Naheliegend wäre: Server antwortet wieder, also sofort alles neu laden. Genau das führt dazu, dass zwanzig Ladevorgänge mit dem alten, längst ungültigen Ausweis losrennen, abgewiesen werden und sich einzeln erholen müssen. Es funktioniert, aber es ist ein Umweg, den man im Protokoll deutlich sieht.

Richtig ist die andere Reihenfolge: erst anmelden, dann laden lassen. Die Anwendung besorgt sich einen gültigen Ausweis, und erst danach bekommen die Ansichten und die offenen Dokumente das Signal, sich zu aktualisieren. Jedes Dokument weiß selbst am besten, was es nachladen muss — es bekommt nur gesagt, dass es soweit ist.

Ein Sonderfall bleibt, und der ist bewusst hart: Wurde der Server in der Zwischenzeit aktualisiert und spricht eine neuere Datenversion, verbindet sich die Anwendung nicht wieder. Dann hilft kein Warten, sondern nur ein Neustart der Anwendung — und genau das sagt sie dann auch, statt mit einem veralteten Verständnis der Daten weiterzuschreiben. Auf diese Ausnahme sind wir fast ein bisschen stolz: Sie ist der einzige Fall, in dem der ungeliebte Satz vom Neustart noch vorkommt, und er steht dort aus gutem Grund.

Was wir daraus mitnehmen

Zwei Dinge, die weit über dieses eine Feature hinausgehen.

Erstens: Ein Ausfall wird selten dort bemerkt, wo man ihn erwartet. Wer nur auf die offensichtlichen Fehler horcht, verpasst die stilleren Varianten — und merkt beim zweiten Mal gar nichts mehr. Wir haben unsere Anwendung deshalb so gebaut, dass mehrere unabhängige Stellen einen Ausfall melden dürfen, aber nur eine einzige entscheidet, was das bedeutet.

Zweitens: Vieles davon hätten wir nie gefunden, wenn wir es nicht ausprobiert hätten. Wir haben den Server im laufenden Betrieb mehrfach gestoppt, wieder gestartet, zwischendurch das Netz getrennt, ungeduldig auf Knöpfe gedrückt — und jedes Mal ins Protokoll geschaut. Der aufschlussreichste Fund kam nicht aus einem Test, sondern aus einer Zeile Protokoll, die zeigte, dass etwas zu früh passierte.

Das Ergebnis merkt man im Alltag hoffentlich gar nicht. Ein kurzes Fenster, das erklärt, was los ist, und wieder verschwindet — und danach steht alles noch so da, wie man es verlassen hat. Genau so soll sich Software anfühlen, wenn die Technik dahinter kurz aus dem Tritt kommt.