Persistenz Advanced: Locking, Audit, Soft Delete und Historisierung
Optimistic Locking, pessimistische Sperren, Audit-Spalten, technische Historisierung und fachliche Nachvollziehbarkeit.
JPAHibernateAuditLocking
In dieser Datei
Optimistic Locking
Optimistic Locking passt, wenn Konflikte selten sind und Benutzer oder Prozesse wiederholen können. Die Version-Spalte schützt vor Lost Updates.
Audit und Historie
Audit-Spalten beantworten technische Fragen. Fachliche Historie beantwortet Business-Fragen. Beide sollten nicht verwechselt werden.
Entscheidungstabelle
| Mechanismus | Wann verwenden? | Risiko |
|---|---|---|
| Optimistic Lock | seltene Konflikte | Retry/Conflict UX nötig |
| Pessimistic Lock | kurze kritische Sequenz | Deadlocks/Throughput |
| Soft Delete | rechtlich/fachlich nötig | Filterfehler |
| History Table | Nachvollziehbarkeit | Datenvolumen |
Praxisübertragung auf das V4-Beispielprojekt
Entscheidung
Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.
Code-Nachweis
Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.
Betrieb
Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.
Typische Fehlerbilder
- Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
- Technische Wiederholung wird nicht idempotent gemacht.
- Observability wird erst nach Produktionsproblem ergänzt.
- Tests prüfen nur Happy Path und keine Wiederanläufe.