Senior Java · Fachbereich

Database & Persistence Workbench

SQL, JPA, JDBC, jOOQ, Transaktionen, Locking, Migrationen und Performance. Nutze die Seite bei Änderungen an Daten oder Schema: Plane Kompatibilität, Migration, Konsistenz, Rückweg und eine messbare Kontrolle nach dem Rollout.

Zur Übersicht

Arbeitsauftrag

Wann verwenden?

Bei Schemaänderungen, Transaktionsproblemen, Sperren oder auffälligen Datenbankzugriffen.

Nicht dafür verwenden

Nicht um fachliche Konsistenz ausschließlich an technische Constraints zu delegieren.

Definition of Done

Migration ist vorwärts- und rückwärtsverträglich; Transaktionen, Indizes, Locks, Datenqualität und Rollback sind geprüft.

Persistenzmodell und Domänenmodell bewusst trennen

Migrationen ohne unnötige Ausfallzeit planen

Query- und Locking-Probleme diagnostizieren

Datenzugriff auswählen

Ansatz	Stärke	Risiko	Prüfung
JPA	Aggregate und Standardzugriffe	versteckte Queries und N+1	SQL- und Transaktionstest
JDBC/jOOQ	explizite SQL-Kontrolle und Reporting	mehr Mappingcode	Queryplan und Integrationstest
Append-only Ledger	Audit und Gegenbuchung	komplexere Projektionen	Invarianten- und Reconciliation-Test

Alle Kapitel

Zugriffstechnologie wählen

JPA ist stark für Aggregate mit klarer Lebensdauer. JDBC oder jOOQ geben bei komplexen SQL-Abfragen und Reporting häufig mehr Kontrolle.

Eine Anwendung darf mehrere Techniken verwenden, wenn die Grenzen klar und der Betriebsaufwand vertretbar sind.

SQL

SELECT o.id, o.status, SUM(l.quantity * l.unit_price) AS total
FROM orders o
JOIN order_lines l ON l.order_id = o.id
WHERE o.created_at >= :from
GROUP BY o.id, o.status
ORDER BY total DESC;

Locking und Konkurrenz

Optimistisches Locking erkennt konkurrierende Änderungen. Pessimistisches Locking verhindert sie durch Sperren, kann aber Durchsatz und Deadlock-Risiko verschlechtern.

Die Entscheidung richtet sich nach Konfliktwahrscheinlichkeit, Kosten eines Retries und Länge der Transaktion.

SQL

UPDATE inventory
SET available = available - :quantity,
    version = version + 1
WHERE product_id = :productId
  AND available >= :quantity
  AND version = :expectedVersion;

Expand and Contract

Kompatible Datenbankänderungen werden in mehreren Deployments umgesetzt: neue Struktur ergänzen, parallel schreiben oder migrieren, Leser umstellen und alte Struktur erst später entfernen.

Praxisartefakt · Schemaänderung

Expand: Nullable-Spalte delivery_window hinzufügen und alten Code weiter betreiben.
Backfill: In begrenzten Batches mit Fortschritts- und Fehlerzählung.
Switch: Neue Version schreibt beide Lesepfade kompatibel.
Contract: Nach vollständiger Nutzung Constraint setzen und alten Pfad entfernen.
Rollback: Alte Anwendung ignoriert die neue Spalte; keine destruktive Migration im selben Release.