mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4fcb4bb48c
meldestelle/docs/database/STARTUP_ORDER_ANALYSIS-de.md
StefanMoCoAt 7e0b56a247 einige Ergänzungen
2025-07-25 23:16:16 +02:00

4.5 KiB
Raw Blame History

Startup-Reihenfolge Analyse - Datenbank-Initialisierung

Aktueller Startup-Ablauf

1. Gateway Startup (Primäre Datenbank-Initialisierung)

  • Datei: infrastructure/gateway/src/main/kotlin/at/mocode/infrastructure/gateway/Application.kt
  • Prozess:
    1. Konfiguration laden (AppConfig)
    2. Datenbankverbindung initialisieren (DatabaseFactory.init(config.database))
    3. Migrationen ausführen (MigrationSetup.runMigrations())
    4. Bei Service Discovery registrieren
    5. Ktor Server starten

2. Service Startup (Nur Schema-Initialisierung)

  • Services: Horses, Events, Masterdata, Members
  • Prozess (über @PostConstruct):
    1. Schema-Initialisierung Start protokollieren
    2. Nur service-spezifisches Schema initialisieren (SchemaUtils.createMissingTablesAndColumns(...))
    3. Schema-Initialisierung Erfolg protokollieren

✅ Gelöste Probleme

1. Gateway Database.connect() Inkonsistenz - BEHOBEN

  • Vorher: Gateway verwendete direkte Database.connect() Aufrufe
  • Nachher: Gateway verwendet DatabaseFactory.init() mit ordnungsgemäßem Connection Pooling
  • Auswirkung: Konsistente Datenbankverbindungsverwaltung über alle Komponenten

2. Race Conditions bei Schema-Initialisierung - BEHOBEN

  • Vorher: Gateway und Services riefen beide DatabaseFactory.init() unabhängig auf
  • Nachher: Nur Gateway ruft DatabaseFactory.init() auf, Services verwalten nur ihre Schemas
  • Auswirkung: Keine Race Conditions mehr während der Datenbankinitialisierung

3. Trennung der Belange - VERBESSERT

  • Vorher: Gateway verwaltete Schemas für alle Services
  • Nachher: Jeder Service verwaltet nur sein eigenes Schema
  • Auswirkung: Bessere Wartbarkeit und klarere Verantwortlichkeiten

Aktuelle Startup-Reihenfolge Koordination

✅ Implizite Koordination (Funktioniert aktuell)

Das aktuelle Setup bietet implizite Startup-Reihenfolge Koordination:

  1. Gateway startet zuerst (typischerweise in Produktionsumgebungen)

    • Initialisiert Datenbankverbindungspool
    • Führt Datenbankmigrationen aus
    • Stellt API-Endpunkte bereit

  2. Services starten unabhängig

    • Jeder Service initialisiert sein eigenes Schema
    • SchemaUtils.createMissingTablesAndColumns() ist idempotent
    • Keine Konflikte, da jeder Service verschiedene Tabellen verwaltet

🔍 Analyse: Ist explizite Koordination erforderlich?

Aktueller Zustand: ✅ AUSREICHEND

  • Datenbankverbindung wird einmal vom Gateway initialisiert
  • Schema-Initialisierung ist idempotent und service-spezifisch
  • Keine Race Conditions oder Konflikte beobachtet
  • Services können in beliebiger Reihenfolge starten ohne Probleme

Mögliche Verbesserungen (Niedrige Priorität):

  • Health Checks hinzufügen, um sicherzustellen, dass Datenbank bereit ist vor Service-Startup
  • Explizite Abhängigkeitsreihenfolge mit @DependsOn Annotationen implementieren
  • Startup-Koordination über Service Discovery hinzufügen

Empfehlungen

✅ Hohe Priorität - ABGESCHLOSSEN

  1. Gateway auf DatabaseFactory umstellen ✅

    • Direkte Database.connect() Aufrufe entfernt
    • Gateway verwendet jetzt DatabaseFactory.init()

  2. Schema-Initialisierung koordinieren ✅

    • Services initialisieren nur ihre eigenen Schemas
    • Doppelte DatabaseFactory.init() Aufrufe entfernt

📋 Mittlere Priorität - OPTIONAL

  1. Startup-Reihenfolge explizit definieren - NICHT ERFORDERLICH
    • Aktuelle implizite Koordination ist ausreichend
    • Services sind darauf ausgelegt, unabhängig zu sein
    • Schema-Operationen sind idempotent

Fazit

Die Datenbankinitialisierungsprobleme wurden erfolgreich gelöst:

✅ Gateway Database.connect() Inkonsistenz - BEHOBEN ✅ Potentielle Race Conditions bei Schema-Initialisierung - BEHOBEN ✅ Fehlende Startup-Reihenfolge-Koordination - AUSREICHEND

Die aktuelle Startup-Reihenfolge Koordination ist angemessen für die Systemanforderungen. Die implizite Koordination durch:

  • Einzelne Datenbankverbindungsinitialisierung (Gateway)
  • Idempotente Schema-Operationen (Services)
  • Unabhängiger Service-Startup

...bietet eine robuste und wartbare Lösung ohne explizite Abhängigkeitsverwaltung zu erfordern.

Testergebnisse

Alle Tests erfolgreich bestanden:

  • ✅ Gateway baut ohne Fehler
  • ✅ Alle Services bauen ohne Fehler
  • ✅ Keine direkten Database.connect() Aufrufe im Gateway
  • ✅ Keine DatabaseFactory.init() Aufrufe in Service-Konfigurationen
  • ✅ Ordnungsgemäße Trennung der Belange beibehalten

Letzte Aktualisierung: 25. Juli 2025