JPA / Hibernate

Problem N+1 w JPA i Hibernate pojawia się wtedy, gdy aplikacje pobierają kolekcje lub relacje w wielu dodatkowych zapytaniach zamiast w jednym kontrolowanym odczycie. Warto sprawdzić strategie fetchingu, użycie Fetch Join, EntityGraph oraz sposób mapowania relacji i kolekcji, a następnie porównać liczbę zapytań w logach SQL lub profilerze. Przykładem jest ekran listy zamówień, w którym pobranie klientów i pozycji zamówień bez analizy lazy loadingu generuje dziesiątki niepotrzebnych odwołań do bazy. Ten temat przerabiamy praktycznie na szkoleniu: Utrwalanie danych z użyciem JPA i Hibernate (JPA/HIB).

JPA jest standardem definiującym API persistence, a Hibernate stanowi jego implementację i rozszerza go o mechanizmy niedostępne w czystej specyfikacji. Należy sprawdzić, czy wymagania obejmują niestandardowe mapowania, cache, filtry, soft delete, audyt lub zaawansowane zarządzanie sesją, bo wtedy rozszerzenia Hibernate często upraszczają implementacje. Dobrym przykładem są pola wyliczane przez @Formula albo mapowania z użyciem @Any, których nie obsługuje samo Jakarta Persistence API. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Zaawansowane aspekty Jakarta Persistence API i Hibernate (HIB/EXT).

Testowanie warstwy persistence powinno obejmować poprawność mapowań, zachowanie transakcji, liczbę wykonywanych zapytań oraz zgodność encji z rzeczywistym schematem bazy. Trzeba sprawdzić scenariusze zapisu, odczytu, lazy loadingu, blokad, kaskad i zapytań agregacyjnych, a także dodać automatyczne asercje wykrywające nadmiarowe odwołania SQL. Przykładem jest test integracyjny, który po zmianie relacji wykrywa wzrost liczby zapytań z 2 do 40 przy pobieraniu listy encji. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Zaawansowane aspekty Jakarta Persistence API i Hibernate (HIB/EXT).

Zaawansowane mapowanie obiektowo-relacyjne obejmuje relacje złożone, obiekty osadzone, kolekcje map, typy kontenerowe, klucze złożone oraz niestandardowe konwersje wartości. W praktyce warto przeanalizować, czy lepiej użyć @EmbeddedId, @MapsId, AttributeConverter, @ElementCollection albo dedykowanej encji relacyjnej, zamiast upraszczać model kosztem spójności danych. Przykładem jest odwzorowanie słownika parametrów jako Map<String, String> lub modelowanie klucza biznesowego z użyciem @NaturalId. To jedno z zagadnień omawianych podczas szkolenia: Zaawansowane aspekty Jakarta Persistence API i Hibernate (HIB/EXT).

Cache w Hibernate obejmuje pamięć pierwszego poziomu związaną z sesją oraz opcjonalny cache drugiego poziomu współdzielony między operacjami i, zależnie od konfiguracji, także cache zapytań. Przed włączeniem cache drugiego poziomu trzeba sprawdzić charakter danych, częstotliwość ich zmian, strategię aktualizacji oraz ryzyko niespójności przy intensywnych zapisach. Typowym przykładem są rzadko modyfikowane słowniki lub dane referencyjne, które aplikacje odczytują bardzo często i z wielu transakcji. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Zaawansowane aspekty Jakarta Persistence API i Hibernate (HIB/EXT).

Blokady optymistyczne i pesymistyczne w JPA służą do kontroli współbieżnego dostępu do rekordów, ale wymagają poprawnego doboru do charakteru operacji i obciążenia systemu. Należy sprawdzić sposób wersjonowania encji, granice transakcji, propagację operacji oraz moment pobierania i zapisu danych, aby ograniczyć konflikty i deadlocki. Przykładem jest jednoczesna edycja tego samego dokumentu przez wielu użytkowników, gdzie @Version wykrywa konflikt, a lock pesymistyczny blokuje zapis konkurencyjnej transakcji. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Utrwalanie danych z użyciem JPA i Hibernate (JPA/HIB).