110 lines
4.5 KiB
Markdown
110 lines
4.5 KiB
Markdown
# 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
|
|
3. **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*
|