Wann Konflikte auftreten
Ein Datenkonflikt tritt auf, wenn derselbe Datensatz aus verschiedenen Quellen geaendert wird, bevor die Aenderungen synchronisiert wurden. Typische Szenarien:
Zwei Geraete offline
Zwei Teammitglieder arbeiten offline auf verschiedenen Geraeten und aendern denselben Datensatz. Zum Beispiel:
- Der Operator am Eingang markiert den Check-in eines Teilnehmers und fuegt den Kommentar "VIP" hinzu
- Der Manager auf einem anderen Geraet markiert denselben Check-in und fuegt den Kommentar "Zusatzplatz" hinzu
- Bei Wiederherstellung der Verbindung werden beide Aenderungen an den Server gesendet
Offline + Online
Ein Teammitglied arbeitet offline, ein anderes online:
- Der Manager am Computer (online) aendert den Registrierungsstatus
- Der Operator vor Ort (offline) aendert denselben Status
- Bei der Synchronisierung steht die Offline-Aenderung im Konflikt mit der bereits angewendeten Online-Aenderung
Wann Konflikte unwahrscheinlich sind
In der Praxis treten Konflikte selten auf, weil:
- Verschiedene Teammitglieder in der Regel mit verschiedenen Teilnehmern arbeiten
- Check-in eine unidirektionale Operation ist (Ankunftsmarkierung), ein Check-in-Konflikt ist nur bei doppeltem Scannen moeglich
- Zahlungsoperationen durch einen Idempotency-Key geschuetzt sind
Strategie: Last-Writer-Wins (Free, Pro)
Bei den Tarifen Free und Pro wird die automatische Strategie Last-Writer-Wins (der letzte Schreiber gewinnt) verwendet:
So funktioniert es
- Bei der Synchronisierung vergleicht der Server die
clientTs-Zeitstempel der konfliktierenden Aenderungen. - Die Aenderung mit dem spaeteren Zeitstempel wird automatisch gespeichert.
- Die Aenderung mit dem frueheren Zeitstempel wird ueberschrieben.
- Beide Aenderungen werden im Audit-Log festgehalten (auch die ueberschriebene).
Beispiel
| Zeit | Aktion | Ergebnis |
|---|---|---|
| 10:05 | Operator A (offline): Check-in + Kommentar "VIP" | Lokal gespeichert |
| 10:07 | Operator B (offline): Check-in + Kommentar "Standard" | Lokal gespeichert |
| 10:15 | Operator A geht online | Aenderung gesendet |
| 10:16 | Operator B geht online | Konflikt. B gewinnt (10:07 > 10:05). Kommentar = "Standard" |
Vorteile und Einschraenkungen
Vorteile:
- Vollautomatisch -- erfordert keinen Benutzereingriff
- Unterbricht den Arbeitsablauf nicht
- Geeignet fuer die meisten Szenarien (Check-in, einfache Status)
Einschraenkungen:
- Die fruehere Aenderung geht ohne Benachrichtigung verloren
- Keine Moeglichkeit, zwei Aenderungen zusammenzufuehren
- Bei kritisch wichtigen Daten kann es zu Informationsverlust kommen
Strategie: Optimistic Locking + Merge-UI (Business, Enterprise)
Bei den Tarifen Business und Enterprise steht eine interaktive Strategie zur Konfliktloesung mit visueller Oberflaeche zur Verfuegung.
So funktioniert es
- Bei der Synchronisierung erkennt der Server einen Konflikt (der Datensatz wurde seit dem letzten bekannten Client-Zustand geaendert).
- Anstatt automatisch zu ueberschreiben, gibt der Server beide Versionen zurueck.
- Dem Benutzer wird die Merge-UI angezeigt -- eine Oberflaeche zum Vergleichen der Versionen.
- Der Benutzer waehlt, welche Version beibehalten werden soll, oder fuegt die Aenderungen manuell zusammen.
Merge-UI
Die Oberflaeche zur Konfliktloesung zeigt:
-
Linke Spalte: Ihre Version (lokale Aenderung)
- Autor der Aenderung
- Zeitpunkt der Aenderung
- Geaenderte Felder mit ihren Werten
-
Rechte Spalte: Serverversion (fremde Aenderung)
- Autor der Aenderung
- Zeitpunkt der Aenderung
- Geaenderte Felder mit ihren Werten
-
Aktionen:
- "Meine Version beibehalten" -- Ihre Aenderung ueberschreibt die Serverversion
- "Serverversion uebernehmen" -- die Serverversion wird beibehalten, Ihre Aenderung verworfen
- "Zusammenfuehren" -- Sie waehlen manuell den Wert fuer jedes Feld
Beispiel
| Feld | Ihre Version | Serverversion |
|---|---|---|
| Check-in | Ja | Ja |
| Kommentar | VIP, Platz A-12 | Standard |
| Status | Bestaetigt | Bestaetigt |
Sie koennen den Check-in aus beiden Versionen uebernehmen (stimmen ueberein), Ihren Kommentar und den Serverstatus uebernehmen.
Optimistic Locking
Im Hintergrund wird Optimistic Locking verwendet:
- Jeder Datensatz hat eine Version (Versionszaehler)
- Beim Senden einer Aenderung gibt der Client an, auf welcher Version sie basiert
- Wenn die Version auf dem Server sich geaendert hat (jemand anderes hat den Datensatz aktualisiert), gibt der Server einen Konflikt zurueck
- Der Client zeigt die Merge-UI
Konfliktbenachrichtigungen
Bei Erkennung eines Konflikts:
Free / Pro: Toast-Benachrichtigung "Datenkonflikt automatisch geloest" (informativ, keine Aktion erforderlich).
Business / Enterprise: Toast-Benachrichtigung "Konflikt erkannt. Ihre Entscheidung erforderlich" mit Schaltflaeche zum Wechsel in die Merge-UI. Der Konflikt blockiert die Synchronisierung der uebrigen Aenderungen, bis er geloest ist.
Empfehlungen
- Teilen Sie Verantwortungsbereiche auf. Weisen Sie Teammitgliedern verschiedene Teilnehmergruppen oder Check-in-Zonen zu, um Konflikte zu minimieren.
- Synchronisieren Sie haeufiger. Kurze Offline-Arbeitsphasen verringern die Konfliktwahrscheinlichkeit.
- Nutzen Sie die Merge-UI fuer kritische Daten. Wenn Ihr Team aktiv mit denselben Datensaetzen arbeitet, erwaegen Sie den Wechsel zu Business fuer den Zugang zur interaktiven Konfliktloesung.