Multi-Client Synchronisation mit Entity Framework 5 – Teil II

Nachdem ich im Teil I den grundsätzlichen Algorithmus des Frameworks zur Multi-Client Synchronisation mit Entity Framework 5 erläutert habe, möchte ich diesen Algorithmus nun Risiko-basiert analysieren.

Die Motivation dieses Vorgehens ist es, das Framework nicht aufzublähen, sondern nur dort zu verfeinern, wo es Sinn macht. Ein Risiko ist in diesem Sinn das Eintreten eines Fehlverhaltens bzw. eine Verhinderung zur Verwendung des Frameworks.

Analyse

Zunächst möchte ich noch einmal einen Schritt zurückgehen und die grundsätzlichen Funktionen des Frameworks skizzieren:

Im Folgenden wird das Ganze noch etwas verfeinert:

Zunächst habe ich ein Brainstorming durchgeführt, was bei einer solchen Synchronisation schief gehen kann. Dabei haben sich Fehler-Custer herauskristallisiert:

  • Basisfunktionalität - im grundsätzlichen Algorithmus ist ein Fehler enthalten
  • Concurrency - durch die Parallelität entstehen komplexe, schwer zu durchschauende Situationen, die evtl. zu ungewolltem Verhalten führen
  • Performance - die Synchronisation könnte die Anwendung nennenswert verlangsamen, den Speicherverbrauch unverhältnismäßig in die Höhe treiben, das Netzwerk belasten und jegliche Skalierbarkeit vernichten
  • Funktionalität – es fehlt eine Funktionalität, um das Framework sinnvoll einzusetzen

Das vorläufige Ergebnis dieser Analyse ist eine Excel-Tabelle, die nach Funktionen gegliedert und nach Gefährdung und Ursache getrennt die Risiken auflistet:

Download Excel Datei: Risikoanalyse.

Manches ist auch unwahrscheinlich, aber die Betrachtungsweise erst einmal weg von der Implementierung und hin zu abstrakten Gefahrenquellen zu lenken, öffnet durchaus den Blick für Probleme, die sonst unbemerkt geblieben wären.

Folgende Änderungen resultieren bereits aus dieser Analyse:

  • Funktionalität: Entfernen der ID-Konvention. Entities müssen nun nicht mehr IEntity implementieren und können mehrteilige Primärschlüssel besitzen
  • Concurrency: Es ist nun je Context oder Einzel-Entity konfigurierbar, was im Kollisionsfall geschehen soll (Einstellungen ClientWins, StoreWins)
  • Concurrency: Die Synchronisation kann für kritische Codeblöcke auf Ebene des Synchronizers (und somit der Session) blockiert werden. Dazu kann ein NoSyncScope erstellt werden
  • Concurrency/Performance: Submits die aktuell von einem Client geschrieben werden, führen nun nicht mehr dazu, dass möglicherweise ein Synchronisationsvorgang (kurzfristig) blockiert wird
  • Dispatcher: die Synchronisierung kann via eines Dispatchers aus dem Hintergrundthread wieder in den UI Thread wechseln, dies funktioniert sowohl für WPF, als auch für Windows Forms

Es gibt jedoch noch einige sinnvolle Änderungen, die noch nicht umgesetzt sind:

  • Einbau eines detaillierten Loggings und auch erweiterter Events
  • Löschen der Log-Tabellen, sodass diese nicht unendlich wachsen (erfordert jedoch Registrierung der Synchroniserer, sodass keine Logs vorzeitig gelöscht werden)
  • Queries aus der Datenbank ermöglichen, die sich automatisch aktualisieren (siehe WPF-Demoanwendung mit Posts und Comments; es betrifft quasi alle Objekte die kein Parent-Objekt besitzen, wie z.B. “Posts” im Blog/Post Beispiel oder das Parent-Objekt nicht geladen ist)

Nun sollte das Framework aber erst einmal eine gewisse Stabilität besitzen, sodass ein Einbau in eine reale Anwendung möglich ist.

Serie

Projekt bei Sourceforge