JPA & JDBC

JDBC ist eine Low-Level-API, bei der SQL-Abfragen manuell formuliert werden müssen. JPA abstrahiert das über ORM, sodass man mit Entitäten arbeitet. Das Framework wie Hibernate generiert das SQL automatisch.

JPA ist die Spezifikation für objekt-relationales Mapping in Java. Hibernate ist eine Implementierung dieser Spezifikation. Man kann sagen: JPA ist das Interface, Hibernate die konkrete Umsetzung.

Relationale Datenbanken speichern Daten in Tabellen mit Beziehungen. Nicht-relationale Datenbanken speichern unstrukturierte oder halbstrukturierte Daten. Relationale Systeme bieten starke Konsistenz, NoSQL-Systeme mehr Skalierbarkeit und Flexibilität.

Statement wird für statische SQLs ohne Parameter verwendet. PreparedStatement ist wiederverwendbar, unterstützt Parameter und schützt vor SQL-Injection. CallableStatement dient zum Aufruf von Stored Procedures.

Jeder Microservice verwaltet seine eigene Datenbank. Daten werden nicht über geteilte Tabellen ausgetauscht. Die Kommunikation erfolgt über REST oder Messaging.

Ich nutze Pagination oder Streaming, um Speicher zu schonen. Zusätzlich kann man Batch-Inserts konfigurieren. Das erhöht die Performance bei großen Datenmengen.

Das Problem entsteht, wenn für jede Entität eine zusätzliche Query ausgeführt wird. Man kann es mit JOIN FETCH, EntityGraph oder Batch-Fetching lösen.

Spring Data nutzt deklaratives Transaktionsmanagement mit @Transactional. Alle Operationen innerhalb der Methode laufen in einer Transaktion. Bei Fehlern erfolgt automatisch ein Rollback.

JPA besitzt einen First-Level-Cache pro EntityManager. Hibernate bietet zusätzlich einen optionalen Second-Level-Cache. Dadurch werden Datenbankabfragen reduziert.

Eine Entität durchläuft die Zustände Transient, Managed, Detached und Removed. Der EntityManager steuert diese Zustände automatisch.

persist fügt eine neue Entität hinzu. merge aktualisiert oder kopiert eine bestehende Entität. save ist ein Spring-Data-Wrapper, der intern persist oder merge nutzt.

Lazy Loading lädt abhängige Entitäten erst bei Bedarf. Eager Loading lädt alle Beziehungen sofort. Eager Loading kann zu Performanceproblemen führen.

Der EntityManager ist Teil der JPA-Spezifikation. Ein Repository ist eine Spring-Data-Abstraktion darüber. Es vereinfacht CRUD-Operationen erheblich.

Eine Entity ist ein persistentes Java-Objekt, das eine Datenbanktabelle repräsentiert. Sie wird mit @Entity markiert. Der Zustand der Entity wird vom EntityManager verwaltet.

Der Persistence Context ist der Arbeitsbereich des EntityManagers. Er verwaltet Entities und dient als First-Level-Cache. Änderungen werden automatisch synchronisiert.

Hibernate erkennt automatisch Änderungen an verwalteten Entities. Beim Flush werden diese Änderungen in SQL übersetzt. Manuelles Update ist nicht nötig.

Flush synchronisiert den Persistence Context mit der Datenbank. SQL-Statements werden ausgeführt, aber nicht committed. Commit beendet die Transaktion.

Optimistic Locking nutzt Versionsfelder zur Konflikterkennung. Es verhindert Datenverlust bei parallelen Zugriffen. Datenbanksperren werden vermieden.

Pessimistic Locking sperrt Datensätze direkt in der Datenbank. Andere Transaktionen müssen warten. Es wird bei kritischen Schreiboperationen genutzt.

Eine Native Query ist reines SQL innerhalb von JPA. Sie wird verwendet, wenn JPQL nicht ausreicht. Sie ist weniger portabel.

JPQL ist eine objektorientierte Abfragesprache. Sie arbeitet mit Entities statt Tabellen. Das macht sie datenbankunabhängig.

Die Criteria API erlaubt typsichere dynamische Abfragen. Sie wird häufig für komplexe Filterlogik genutzt. Der Code ist jedoch schwerer lesbar.

Projections erlauben das Laden nur bestimmter Felder. Dadurch werden Performance und Speicherverbrauch verbessert. Sie können als Interface oder Klasse definiert werden.

Batch Processing bündelt mehrere SQL-Statements. Das reduziert Roundtrips zur Datenbank. Es ist besonders bei Inserts und Updates sinnvoll.

Diese Einstellung steuert die Größe von SQL-Batches. Größere Batches verbessern die Performance. Sie müssen datenbankabhängig getestet werden.

save speichert die Entität im Persistence Context. saveAndFlush schreibt sofort in die Datenbank. Das kann für Konsistenz wichtig sein.

Dieses Pattern hält die Session bis zum View-Layer offen. Es ermöglicht Lazy Loading in Views. Es kann aber versteckte Performanceprobleme verursachen.

Bei sehr komplexen Reports oder stark optimiertem SQL. JDBC bietet maximale Kontrolle. Der Entwicklungsaufwand ist jedoch höher.

Man nutzt meist In-Memory-Datenbanken wie H2. Tests laufen isoliert und schnell. Spring bietet dafür @DataJpaTest.

Sie bestimmt, wie Transaktionen sich gegenseitig beeinflussen. Beispiele sind Read Committed oder Serializable. Höhere Isolation reduziert Nebenwirkungen, kostet aber Performance.

JPA kann Datenbankschemata automatisch erzeugen. Das wird meist in Entwicklung genutzt. In Produktion ist es riskant.

LAZY lädt Beziehungen erst bei Zugriff. EAGER lädt sie sofort. Falsche Nutzung kann Performanceprobleme verursachen.

Bei extrem komplexem SQL oder datenbankspezifischen Features. Auch bei sehr großen Datenmengen kann JDBC sinnvoller sein.