Hibernate w akcji

Wydawnictwo Helionul. Koœciuszki 1c44-100 Gliwicetel. 032 230 98 63e-mail: [email protected]

Hibernate w akcji

Szukasz rozwi¹zania problemów zwi¹zanych z korzystaniem z relacyjnych baz danych w po³¹czeniu z programowaniem obiektowym? Chcesz poprawiæ wydajnoœæ i jakoœæ aplikacji bazodanowych? A mo¿e rozwi¹zania, które stosowa³eœ dotychczas, okazuj¹ siê niewystarczaj¹ce przy du¿ych projektach? Siêgnij po Hibernate, czyli rewolucyjne narzêdzie stanowi¹ce warstwê poœrednicz¹c¹ pomiêdzy aplikacj¹ i baz¹ danych, umo¿liwiaj¹ce utrwalanie i odczyt obiektów Javy w bazie. Hibernate eliminuje koniecznoœæ rêcznego tworzenia kodu odwzorowuj¹cego obiekty na model relacyjny i odwrotnie,a tak¿e znacz¹co poprawia wydajnoœæ i stabilnoœæ aplikacji. Nie bez znaczenia równie¿ jest fakt, i¿ Hibernate dostêpne jest na licencji open-source.

Ksi¹¿ka „Hibernate w akcji”, napisana przez twórców tego narzêdzia. To wyczerpuj¹cy podrêcznik dla programistów, którzy planuj¹ zastosowaæ je w swoich projektach. Czytaj¹c j¹, dowiesz siê, na czym polega odwzorowanie obiektowo-relacyjne i w jaki sposób implementuje je Hibernate. Poznasz zasady tworzenia i stosowania obiektów trwa³ych, zarz¹dzania transakcjami i buforowania danych. Znajdziesz tak¿e informacjeo optymalizowaniu wydajnoœci aplikacji stosuj¹cych Hibernate oraz procesie projektowania takich aplikacji.

W ksi¹¿ce poruszono m.in.:

• Odwzorowania obiektowo-relacyjne• Konfiguracja i uruchomienie Hibernate• Odwzorowywanie danych w klasach• Stosowanie obiektów trwa³ych• Transakcje i buforowanie• Wydajne pobieranie obiektów z bazy• Projektowanie aplikacji wykorzystuj¹cych Hibernate• Narzêdzia wspomagaj¹ce dzia³anie Hibernate

Poznaj Hibernate i przekonaj siê, jak dziêki niemu usprawnisz swoj¹ pracê

Autorzy: Christian Bauer, Gavin KingT³umaczenie: Rafa³ JoñcaISBN: 83-246-0527-4Tytu³ orygina³u: Hibernate in ActionFormat: B5, stron: 410

http://helion.pl/view/2547w



http://helion.pl/add/2547w/hibakc




mailto:[email protected]

http://helion.pl/view/2547w/hibakc.htm

http://www.amazon.com/exec/obidos/ASIN/193239415X/eboinf-20

Spis treści

Przedmowa 9Wstęp 11Podziękowania 13O książce i autorach 15O Hibernate 3 i EJB 3 19

1. Trwałość dzięki odwzorowaniu obiektowo-relacyjnemu 211.1. Czym jest trwałość? .............................................................................................................. 23

1.1.1. Relacyjne bazy danych ............................................................................................. 231.1.2. Język SQL ................................................................................................................. 241.1.3. Korzystanie z SQL w Javie ....................................................................................... 241.1.4. Trwałość w aplikacjach obiektowych ....................................................................... 25

1.2. Niedopasowanie paradygmatów ......................................................................................... 271.2.1. Problem szczegółowości ........................................................................................... 281.2.2. Problem podtypów .................................................................................................... 291.2.3. Problem identyczności ............................................................................................. 301.2.4. Problemy dotyczące asocjacji ................................................................................... 321.2.5. Problem nawigacji po grafie obiektów ..................................................................... 331.2.6. Koszt niedopasowania ............................................................................................... 34

1.3. Warstwy trwałości i alternatywy ........................................................................................ 351.3.1. Architektura warstwowa ........................................................................................... 351.3.2. Ręczne tworzenie warstwy trwałości za pomocą SQL i JDBC .............................. 371.3.3. Wykorzystanie serializacji ........................................................................................ 381.3.4. A może ziarenka encyjne EJB? ................................................................................ 39

4 Spis treści

1.3.5. Obiektowe systemy bazodanowe ............................................................................. 401.3.6. Inne rozwiązania ....................................................................................................... 41

1.4. Odwzorowanie obiektowo-relacyjne .................................................................................. 411.4.1. Czym jest ORM? ....................................................................................................... 421.4.2. Ogólne problemy ORM ............................................................................................ 441.4.3. Dlaczego ORM? ........................................................................................................ 45

1.5. Podsumowanie ...................................................................................................................... 47

2. Wprowadzenie i integracja Hibernate 492.1. „Witaj świecie” w stylu Hibernate ...................................................................................... 502.2. Podstawy architektury Hibernate ...................................................................................... 55

2.2.1. Interfejsy podstawowe .............................................................................................. 562.2.2. Interfejsy wywołań zwrotnych ................................................................................. 582.2.3. Typy ........................................................................................................................... 582.2.4. Interfejsy rozszerzeń ................................................................................................ 59

2.3. Konfiguracja podstawowa .................................................................................................... 592.3.1. Tworzenie obiektu SessionFactory .......................................................................... 602.3.2. Konfiguracja w środowisku niezarządzanym .......................................................... 622.3.3. Konfiguracja w środowisku zarządzanym ................................................................ 66

2.4. Zaawansowane ustawienia konfiguracyjne ........................................................................ 682.4.1. Konfiguracja bazująca na pliku XML ...................................................................... 692.4.2. Obiekt SessionFactory dowiązany do JNDI ........................................................... 702.4.3. Dzienniki ................................................................................................................... 712.4.4. Java Management Extensions .................................................................................. 73

2.5. Podsumowanie ...................................................................................................................... 75

3. Odwzorowanie klas trwałości danych 773.1. Aplikacja CaveatEmptor ..................................................................................................... 78

3.1.1. Analiza dziedziny biznesowej .................................................................................. 793.1.2. Model dziedzinowy CaveatEmptor ......................................................................... 79

3.2. Implementacja modelu dziedzinowego .............................................................................. 823.2.1. Kwestia przesiąkania zadań ...................................................................................... 823.2.2. Trwałość automatyczna i przezroczysta ................................................................... 833.2.3. Tworzenie klas POJO ............................................................................................... 843.2.4. Implementacja asocjacji POJO ................................................................................. 863.2.5. Dodanie logiki do metod dostępowych ................................................................... 90

3.3. Definicja metadanych odwzorowujących .......................................................................... 923.3.1. Metadane w pliku XML ........................................................................................... 923.3.2. Podstawowe odwzorowania właściwości i klas ........................................................ 953.3.3. Programowanie zorientowane na atrybuty ............................................................ 1013.3.4. Modyfikacja metadanych w trakcie działania aplikacji ......................................... 102

3.4. Identyczność obiektów ....................................................................................................... 1043.4.1. Identyczność a równość .......................................................................................... 1043.4.2. Tożsamość bazodanowa w Hibernate .................................................................... 1043.4.3. Wybór kluczy głównych ......................................................................................... 106

3.5. Szczegółowe modele obiektów .......................................................................................... 1083.5.1. Encje i typy wartości .............................................................................................. 1093.5.2. Stosowanie komponentów ...................................................................................... 109

3.6. Odwzorowanie dziedziczenia klas .................................................................................... 1133.6.1. Tabela na klasę konkretną ...................................................................................... 1133.6.2. Tabela na każdą hierarchię klas ............................................................................. 115

Spis treści 5

3.6.3. Tabela na każdą podklasę ....................................................................................... 1173.6.4. Wybór strategii ........................................................................................................ 120

3.7. Asocjacje .............................................................................................................................. 1213.7.1. Asocjacje zarządzane? ............................................................................................. 1213.7.2. Krotność .................................................................................................................. 1223.7.3. Najprostsza możliwa asocjacja ............................................................................... 1223.7.4. Tworzenie asocjacji dwukierunkowej .................................................................... 1233.7.5. Związek rodzic-potomek ........................................................................................ 126

3.8. Podsumowanie .................................................................................................................... 127

4. Stosowanie obiektów trwałych 1294.1. Cykl życia obiektu trwałego .............................................................................................. 130

4.1.1. Obiekty ulotne ........................................................................................................ 1314.1.2. Obiekty trwałe ......................................................................................................... 1324.1.3. Obiekt odłączony .................................................................................................... 1334.1.4. Zasięg identyczności obiektów ............................................................................... 1344.1.5. Poza zasięgiem identyczności ................................................................................ 1354.1.6. Implementacja equals() i hashCode() .................................................................... 136

4.2. Zarządca trwałości .............................................................................................................. 1404.2.1. Czynienie obiektu trwałym .................................................................................... 1404.2.2. Aktualizacja stanu trwałego obiektu odłączonego ................................................. 1414.2.3. Pobranie obiektu trwałego ..................................................................................... 1424.2.4. Aktualizacja obiektu trwałego ................................................................................ 1434.2.5. Zmiana obiektu trwałego na ulotny ....................................................................... 1434.2.6. Zmiana obiektu odłączonego na ulotny ................................................................. 144

4.3. Trwałość przechodnia w Hibernate ................................................................................. 1444.3.1. Przechodniość przez osiągalność ........................................................................... 1454.3.2. Trwałość kaskadowa w Hibernate ......................................................................... 1464.3.3. Zarządzanie kategoriami przedmiotów .................................................................. 1474.3.4. Rozróżnienie obiektów ulotnych i odłączonych .................................................... 151

4.4. Pobieranie obiektów ........................................................................................................... 1524.4.1. Pobieranie obiektów na podstawie identyfikatora ................................................ 1534.4.2. Wprowadzenie do HQL ......................................................................................... 1544.4.3. Zapytania przez określenie kryteriów .................................................................... 1554.4.4. Zapytanie przez przykład ....................................................................................... 1554.4.5. Strategie sprowadzania danych .............................................................................. 1564.4.6. Wybór strategii sprowadzania w odwzorowaniach ............................................... 1584.4.7. Optymalizacja pobierania obiektów ....................................................................... 163

4.5. Podsumowanie .................................................................................................................... 164

5. Transakcje, współbieżność i buforowanie 1675.1. Transakcje bazodanowe ..................................................................................................... 169

5.1.1. Transakcje JDBC i JTA .......................................................................................... 1705.1.2. Interfejs Transaction ............................................................................................... 1715.1.3. Opróżnianie sesji ..................................................................................................... 1735.1.4. Poziomy izolacji ...................................................................................................... 1745.1.5. Wybór poziomu izolacji .......................................................................................... 1765.1.6. Ustawianie poziomu izolacji ................................................................................... 1775.1.7. Blokada pesymistyczna ........................................................................................... 177

5.2. Transakcje aplikacyjne ...................................................................................................... 1805.2.1. Wersjonowanie zarządzane .................................................................................... 181

6 Spis treści

5.2.2. Szczegółowość sesji ................................................................................................ 1845.2.3. Inne sposoby implementacji blokady optymistycznej .......................................... 185

5.3. Buforowanie — teoria i praktyka ..................................................................................... 1865.3.1. Strategie i zasięgi buforowania ............................................................................... 1875.3.2. Architektura buforów Hibernate ............................................................................ 1905.3.3. Buforowanie w praktyce ......................................................................................... 195

5.4. Podsumowanie .................................................................................................................... 204

6. Zaawansowane zagadnienia odwzorowań 2056.1. System typów Hibernate .................................................................................................... 206

6.1.1. Wbudowane typy odwzorowań .............................................................................. 2076.1.2. Zastosowania typów odwzorowań .......................................................................... 210

6.2. Odwzorowywanie kolekcji typów wartości ...................................................................... 2206.2.1. Zbiory, pojemniki, listy i odwzorowania ................................................................ 220

6.3. Odwzorowanie asocjacji encyjnych .................................................................................. 2286.3.1. Asocjacja jeden-do-jednego .................................................................................... 2296.3.2. Asocjacje wiele-do-wielu ........................................................................................ 232

6.4. Odwzorowanie asocjacji polimorficznych ....................................................................... 2416.4.1. Polimorficzna asocjacja wiele-do-jednego ............................................................. 2416.4.2. Kolekcje polimorficzne ........................................................................................... 2436.4.3. Asocjacje polimorficzne i jedna tabela na klasę konkretną ................................... 244

6.5. Podsumowanie .................................................................................................................... 246

7. Wydajne pobieranie obiektów 2477.1. Wykonywanie zapytań ....................................................................................................... 249

7.1.1. Interfejsy zapytań ................................................................................................... 2497.1.2. Dowiązywanie parametrów .................................................................................... 2517.1.3. Zapytania nazwane .................................................................................................. 254

7.2. Proste zapytania dotyczące obiektów ............................................................................... 2557.2.1. Najprostsze zapytanie ............................................................................................. 2567.2.2. Zastosowanie aliasów .............................................................................................. 2567.2.3. Zapytania polimorficzne ......................................................................................... 2577.2.4. Ograniczenia ........................................................................................................... 2577.2.5. Operatory porównań ............................................................................................... 2587.2.6. Dopasowywanie tekstów ........................................................................................ 2607.2.7. Operatory logiczne .................................................................................................. 2617.2.8. Kolejność wyników zapytań ................................................................................... 262

7.3. Złączanie asocjacji .............................................................................................................. 2627.3.1. Złączenia w Hibernate ............................................................................................ 2647.3.2. Pobieranie asocjacji ................................................................................................ 2657.3.3. Aliasy i złączenia ..................................................................................................... 2667.3.4. Złączenia niejawne .................................................................................................. 2707.3.5. Złączenia w stylu theta ........................................................................................... 2717.3.6. Porównywanie identyfikatorów .............................................................................. 272

7.4. Tworzenie zapytań raportujących .................................................................................... 2737.4.1. Projekcja .................................................................................................................. 2747.4.2. Agregacja ................................................................................................................. 2767.4.3. Grupowanie ............................................................................................................. 2777.4.4. Ograniczanie grup klauzulą having ........................................................................ 2787.4.5. Poprawa wydajności zapytań raportujących .......................................................... 279

Spis treści 7

7.5. Techniki tworzenia zaawansowanych zapytań ................................................................ 2797.5.1. Zapytania dynamiczne ............................................................................................ 2807.5.2. Filtry kolekcji .......................................................................................................... 2827.5.3. Podzapytania ........................................................................................................... 2847.5.4. Zapytania SQL ........................................................................................................ 286

7.6. Optymalizacja pobierania obiektów ................................................................................. 2887.6.1. Rozwiązanie problemu n+1 pobrań danych ......................................................... 2887.6.2. Zapytania iterate() ................................................................................................... 2917.6.3. Buforowanie zapytań .............................................................................................. 292

7.7. Podsumowanie .................................................................................................................... 294

8. Tworzenie aplikacji stosujących Hibernate 2958.1. Projektowanie aplikacji warstwowych ............................................................................. 296

8.1.1. Użycie Hibernate w systemie serwletowym ......................................................... 2978.1.2. Stosowanie Hibernate w kontenerze EJB ............................................................. 311

8.2. Implementacja transakcji aplikacyjnych ......................................................................... 3198.2.2. Trudny sposób ......................................................................................................... 3218.2.3. Odłączone obiekty trwałe ....................................................................................... 3228.2.4. Długa sesja .............................................................................................................. 3238.2.5. Wybór odpowiedniej implementacji transakcji aplikacyjnych ............................ 327

8.3. Obsługa specjalnych rodzajów danych ............................................................................ 3288.3.1. Starsze schematy baz danych i klucze złożone ..................................................... 3288.3.2. Dziennik audytowy ................................................................................................. 337

8.4. Podsumowanie .................................................................................................................... 343

9. Narzędzia Hibernate 3459.1. Procesy tworzenia aplikacji ............................................................................................... 346

9.1.1. Podejście z góry na dół ........................................................................................... 3479.1.2. Podejście z dołu do góry ......................................................................................... 3479.1.3. Podejście od środka ................................................................................................ 3479.1.4. Spotkanie w środku ................................................................................................. 3479.1.5. Ścieżka przejścia ..................................................................................................... 348

9.2. Automatyczne generowanie schematu bazy danych ....................................................... 3489.2.1. Przygotowanie metadanych odwzorowania ........................................................... 3499.2.2. Utworzenie schematu ............................................................................................. 3519.2.3. Aktualizacja schematu bazy danych ....................................................................... 353

9.3. Generowanie kodu klas POJO ........................................................................................... 3549.3.1. Wprowadzenie metaatrybutów .............................................................................. 3559.3.2. Metody odnajdujące ............................................................................................... 3579.3.3. Konfiguracja hbm2java ........................................................................................... 3589.3.4. Uruchamianie narzędzia hbm2java ........................................................................ 359

9.4. Istniejące schematy i Middlegen ...................................................................................... 3609.4.1. Uruchomienie Middlegen ...................................................................................... 3609.4.2. Ograniczanie tabel i związków ............................................................................... 3629.4.3. Dostosowanie generowania metadanych ............................................................... 3639.4.4. Generowanie metadanych hbm2java i XDoclet .................................................... 365

9.5. XDoclet ................................................................................................................................ 3669.5.1. Ustawianie atrybutów typu wartości ...................................................................... 3679.5.2. Odwzorowanie asocjacji encyjnych ....................................................................... 3689.5.3. Uruchomienie XDoclet .......................................................................................... 369

9.6. Podsumowanie .................................................................................................................... 371

8 Spis treści

A Podstawy języka SQL 373

B Strategie implementacji systemów ORM 377B.1. Właściwości czy pola? ........................................................................................................ 378B.2. Strategie sprawdzania zabrudzenia .................................................................................. 379

B.2.1. Dziedziczenie po wygenerowanym kodzie ........................................................... 379B.2.2. Przetwarzanie kodu źródłowego ............................................................................ 379B.2.3. Przetwarzanie kodu bajtowego .............................................................................. 380B.2.4. Introspekcja ............................................................................................................. 380B.2.5. Generowanie kodu bajtowego „w locie” ................................................................ 381B.2.6. Obiekty „uogólnione” ............................................................................................. 382

C Powrót do świata rzeczywistego 383C.1. Dziwna kopia ...................................................................................................................... 384C.2. Im więcej, tym lepiej .......................................................................................................... 385C.3. Nie potrzebujemy kluczy głównych .................................................................................. 385C.4. Czas nie jest liniowy ........................................................................................................... 386C.5. Dynamicznie niebezpieczne .............................................................................................. 386C.6. Synchronizować czy nie synchronizować? ....................................................................... 387C.7. Naprawdę gruby klient ...................................................................................................... 388C.8. Wznawianie Hibernate ...................................................................................................... 388

Bibliografia 391Skorowidz 393

Wprowadzeniei integracja Hibernate

W rozdziale:

♦ Działanie Hibernate na przykładzie aplikacji„Witaj świecie”

♦ Podstawowe interfejsy programistyczneHibernate

♦ Integracja z zarządzanymi i niezarządzanymiśrodowiskami

♦ Zaawansowane opcje konfiguracyjne

50 ROZDZIAŁ 2.Wprowadzenie i integracja Hibernate

Dobrze zdawać sobie sprawę z potrzeby odwzorowania obiektowo-relacyjnegow aplikacjach Javy, ale jeszcze lepiej zobaczyć takie odwzorowanie w akcji. Za-cznijmy od prostego przykładu obrazującego zalety Hibernate.

Wiele osób wie, że niemal każda książka o programowaniu rozpoczyna się odprzykładu „Witaj świecie”. Nie zamierzamy się wyłamywać z tej konwencji i rów-nież przedstawimy prostą aplikację tego typu używającą Hibernate. Niestety, pro-ste wyświetlenie komunikatu tekstowego na konsoli nie uwidoczniłoby żadnychzalet Hibernate. Z tego powodu tworzony program będzie tworzył nowe obiektyw bazie danych, aktualizował je i wykonywał zapytania, by je pobrać.

Niniejszy rozdział stanowi podstawę dla pozostałych rozdziałów. Poza przed-stawieniem typowego dla książek informatycznych przykładu wprowadzimy rów-nież interfejs programistyczny Hibernate i omówimy konfigurację systemu w róż-nych środowiskach wykonawczych, na przykład serwerach aplikacji J2EE lubaplikacjach klienckich.

2.1. „Witaj świecie” w stylu Hibernate

Aplikacje Hibernate definiują klasy trwałe, które są odwzorowywane na tabelebazy danych. Pierwszy przykład zawiera jedną klasę i jeden plik opisu odwzo-rowania. Przyjrzyjmy się, jak wygląda prosta klasa trwałości, jak określa się odwzo-rowanie i jak wykonuje się podstawowe operacje dotyczące trwałości danych.

Celem pierwszej aplikacji jest zapamiętywanie w bazie danych komunikatów,a następnie ich pobieranie w celu wyświetlania. Aplikacja stosuje prostą klasętrwałości, Message, reprezentującą komunikaty do wyświetlenia. Klasę przedsta-wia listing 2.1.

Listing 2.1. Plik Message.java — prosta klasa trwałości

package hello;public class Message { private Long id; private String text; private Message nextMessage; private Message() {} public Message(String text) { this.text = text; } public Long getId() { return id; } private void setId(Long id) { this.id = id; } public String getText() { return text; } private void setText(String text) { this.text= text; }

2.1. „Witaj świecie” w stylu Hibernate 51

public Long getNextMessage() { return nextMessage; } private void setnNextMessage(Long nextMessage) { this.nextMessage= nextMessage; }

Klasa Message ma trzy atrybuty: identyfikator, treść komunikatu i referencję doinnego komunikatu. Atrybut identyfikacyjny umożliwia aplikacji dostęp do iden-tyfikatora bazodanowego — wartości klucza głównego — obiektu trwałego. Jeślidwa egzemplarze klasy Message zawierają ten sam identyfikator, dotyczą tego same-go wiersza w tabeli bazy danych. Jako typ identyfikatora wybraliśmy Long, choćnie jest to wymóg. Hibernate dopuszcza stosowane dla identyfikatorów dowolnychtypów, co wkrótce przedstawimy.

Wszystkie atrybuty klasy Message stosują metody dostępowe do właściwościw stylu ziarenek JavaBeans. Klasa zawiera także bezparametrowy konstruktor.Klasy trwałości stosowane w kolejnych przykładach wyglądają bardzo podobniedo przedstawionej.

Egzemplarze klasy Message mogą być zarządzane (w sensie zapewnienia trwa-łości) przez Hibernate, ale nie jest to przymus. Ponieważ obiekt Message nie imple-mentuje żadnych klas i interfejsów specyficznych dla Hibernate, można go używaćjak dowolnej innej klasy Javy.

Message message = new Message("Witaj świecie");System.out.println(message.getText());

Przedstawiony fragment wykonuje właśnie to zadanie, którego oczekuje się poaplikacji „Witaj świecie” — wyświetla na konsoli napis Witaj świecie. Niektó-rym wydaje się zapewne, że w tym momencie jesteśmy wyjątkowo uprzejmi —w rzeczywistości ten prosty przykład demonstruje istotną cechę wyróżniającąHiberante od innych rozwiązań trwałości, na przykład ziarenek encyjnych EJB.Klasę trwałości można stosować w dowolnym kontekście, bo nie jest koniecznyżaden szczególny kontener. Ponieważ książka dotyczy Hibernate, zapiszmy obiektMessage do bazy danych.

Session session = getSessionFactory().openSession();Transaction tx = session.beginTransaction();Message message = new Message("Witaj świecie");session.save(message);tx.commit();session.close();

Przedstawiony kod korzysta z interfejsów Session i Transaction systemu Hiber-nate (wkrótce zajmiemy się wywołaniem getSessionFactory()). Przedstawionykod skutkuje przekazaniem do bazy danych polecenia SQL podobnego do nastę-pującego:

insert into MESSSAGE (MESSAGE_ID, MESSAGE_TEXT, NEXT_MESSAGE_ID) values(1, 'Witaj świecie', null)


Chwileczkę — kolumna MESSAGE_ID zostaje zainicjalizowana dziwną wartością.Nigdzie nie ustawialiśmy w kodzie właściwości id, więc oczekujemy dla niej war-tości null, prawda? W rzeczywistości właściwość id jest szczególna — jest wła-ściwością identyfikującą, która przechowuje wygenerowaną, unikatową wartość(w dalszej części tekstu wyjaśnimy sposób generowania wartości). Wartość zostajewprowadzona do obiektu Message w momencie wykonania metody save().

W przykładzie zakładamy wcześniejsze istnienie tabeli MESSAGE. W rozdziale9. omówimy wykorzystanie Hibernate do automatycznego tworzenia tabel wyma-ganych przez aplikację dzięki informacjom zawartym w plikach odwzorowań(w ten sposób unikamy pisania jeszcze większej ilości kodu SQL). Chcemy, byprogram wyświetlił komunikat na konsoli. Skoro komunikat znalazł się w baziedanych, nie powinno to sprawić żadnych trudności. Kolejny przykład pobieraz bazy danych wszystkie komunikaty w kolejności alfabetycznej i wyświetla ichzawartość.

Session newSession = getSessionFactory().openSession();Transaction newTransaction = newSession.beginTransaction();List messages = newSession.find("from Message as m order by m.text asc");System.out.println("Znalezionych komunikatów: " + messages.size());for (Iterator iter = messages.iterator(); iter.hasNext();) { Message message = (Message) iter.next(); System.out.println(message.getText());}newTransaction.commit();newSession.close();

Ciąg znaków "from Message as m order by m.text asc" to zapytanie Hibernatezapisane w specjalnym, obiektowym języku zapytań Hibernate (HQL — Hiber-nate Query Language). Zapytanie zostaje wewnętrznie przekształcone na nastę-pujący kod SQL w momencie wywołania metody find().

select m.MESSAGE_ID, m.MESSAGE_TEXT, m.NEXT_MESSAGE_IDfrom MESSAGES morder by m.MESSAGE_TEXT asc

Przedstawiony kod powoduje wyświetlenie na konsoli poniższego tekstu:

Znalezionych komunikatów: 1Witaj świecie

Jeśli ktoś nigdy wcześniej nie korzystał z narzędzi ORM, spodziewa się ujrzeć kodSQL w metadanych lub też kodzie Javy. Nie ma go tam. Cały kod SQL zostajewygenerowany dynamicznie w trakcie działania aplikacji (ewentualnie w momen-cie jej uruchamiania dla wszystkich instrukcji SQL wielokrotnego użytku).

Aby wystąpiła cała magia, Hibernate potrzebuje więcej informacji na tematzapewniania trwałości klasie Message. Informację tę najczęściej umieszcza siędokumencie odwzorowania zapisywanym w formacie XML. Dokument ten defi-niuje, poza innymi kwestiami, w jaki sposób przełożyć właściwości klasy Messagena kolumny tabeli MESSAGES. Przyjrzyjmy się fragmentowi dokumentu odwzoro-wania — listing 2.2.

2.1. „Witaj świecie” w stylu Hibernate 53

Listing 2.2. Prosty plik odwzorowania Hibernate w formacie XML

<?xml version="1.0"?><!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN""http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"><hibernate-mapping> <class name="hello.Message" table="MESSAGES"> <id name="id" column="MESSAGE_ID"> <generator class="increment"/> </id> <property name="text" column="MESSAGE_TEXT"/> <many-to-one name="nextMessage" cascade="all" column="NEXT_MESSAGE_ID"/> </class></hibernate-mapping>

Dokument odwzorowania informuje Hibernate, że klasa Message przekłada sięna tabelę MESSAGES. Informuje również, że właściwość identyfikatora ma trafić dokolumny nazwanej MESSAGE_ID, właściwość komunikatu do kolumny o nazwieMESSAGE_TEXT, natomiast właściwość nextMessage jest asocjacją z krotnością wiele-do-jednego i powinna trafić do kolumny o nazwie NEXT_MESSAGE_ID (pozostałymiszczegółami na tym etapie nie będziemy się zajmować).

Dokument XML nie jest trudny do zrozumienia. Można go bez problemówręcznie tworzyć i modyfikować. W rozdziale 3. omówimy sposób generowania tegopliku na podstawie komentarzy zawartych w kodzie źródłowym aplikacji. Nie-zależnie od wybranego podejścia Hiberante uzyskuje wystarczająco dużo infor-macji, by poprawnie generować wszystkie polecenia SQL dotyczące wstawiania,aktualizacji, usuwania i pobierania egzemplarzy klasy Message. Nie trzeba ręczniepisać wszystkich wymaganych poleceń SQL.

Uwaga Wielu programistów Javy narzeka na tak zwane „piekło metadanych”,które towarzyszy tworzeniu oprogramowania J2EE. Niektórzy sugerująnawet rezygnację z metadanych XML i powrót do zwykłego kodu Javy.Choć w pełni popieramy te dążenia w niektórych dziedzinach, ORMwydaje się być zagadnieniem, w którym metadane naprawdę są potrzebne.Hibernate stosuje sensowne wartości domyślne, by zminimalizować dłu-gość plików konfiguracyjnych. Wykorzystuje dojrzałą definicję typu doku-mentu (DTD), więc możliwe jest wykorzystanie edytorów z uzupełnianiemskładni i walidacją. Istnieją nawet narzędzia zapewniające automatycznegenerowanie metadanych.


Zmieńmy pierwszy komunikat i dodatkowo utwórzmy kolejny powiązany z pierw-szym. Kod wykonujący to zadanie przedstawia listing 2.3.

Listing 2.3. Aktualizacja komunikatu

Session session = getSessionFactory().openSession();Transaction tx = session.beginTransaction();

// 1 to identyfikator wygenerowany dla pierwszego komunikatuMessage message = (Message) session.load(Message.class, new Long(1));message.setText("Witajcie Ziemianie");Message nextMessage = new Message("Proszę zabrać mnie do waszego przywódcy");message.setNextMessage(nextMessage);tx.commit();session.close();

Powyższy kod powoduje wykonanie w jednej transakcji trzech poleceń SQL.

select m.MESSAGE_ID, m.MESSAGE_TEXT, m.NEXT_MESSAGE_IDfrom MESSAGES mwhere m.MESSAGE_ID = 1

insert into MESSAGES (MESSAGE_ID, MESSAGE_TEXT, NEXT_MESSAGE_ID)values (2, 'Proszę zabrać mnie do waszego przywódcy', null)

update MESSAGESset MESSAGE_TEXT = 'Witajcie Ziemianie', NEXT_MESSAGE_ID = 2where MESSAGE_ID = 1

Zauważ, że Hibernate automatycznie rozpoznał modyfikację właściwości texti nextMessage dla pierwszego komunikatu i zapisał nowe wartości w bazie danych.Skorzystaliśmy z cechy Hibernate nazywanej automatycznym wykrywaniemzabrudzenia. Pozwala ona uniknąć jawnego proszenia Hibernate o aktualizacjębazy danych, gdy zmienia się stan obiektu wewnątrz transakcji. Warto zwrócićuwagę, iż nowy komunikat również stał się trwały, gdy tylko powstała referencjado niego z pierwszego komunikatu. Jest to tak zwany zapis kaskadowy — unikasię w ten sposób jawnego wywoływania metody save() dla nowego obiektu trwa-łego, o ile tylko jest on osiągalny z poziomu innego obiektu trwałego. Kolejnośćwykonania instrukcji SQL nie jest taka sama jak kolejność modyfikacji wartościwłaściwości. Hibernate używa wyrafinowanego algorytmu do określenia wydajnejkolejności zapisów, by uniknąć zerwania ograniczeń klucza obcego i jednocześniepozostać odpowiednio przewidywalnym. Jest to tak zwany transakcyjny zapis opóź-niony.

Ponownie uruchomienie programu spowoduje wyświetlenie poniższegowyniku:

Znalezionych komunikatów: 2Witajcie ZiemianieProszę zabrać mnie do waszego przywódcy

2.2. Podstawy architektury Hibernate 55

Na tym zakończymy przygodę z aplikacją „Witaj świecie”. Gdy poznaliśmy dzia-łający kod, możemy się cofnąć i dokładniej omówić poszczególne elementy głów-nego interfejsu programistycznego Hibernate.

2.2. Podstawy architektury Hibernate

Interfejs programistyczny to pierwszy element Hibernate, który trzeba poznać,by móc skorzystać z warstwy trwałości w aplikacji. Głównym celem projektowyminterfejsu była minimalizacja współzależności między poszczególnymi kompo-nentami oprogramowania. W praktyce interfejs programistyczny ORM nie należydo najmniejszych. Na szczęście nie wszystkie interfejsy trzeba poznać od razu, bykorzystać z Hibernate. Rysunek 2.1 przedstawia zadania najważniejszych interfej-sów w warstwie biznesowej i trwałości. Na rysunku warstwa biznesowa znajdujesię powyżej warstwy trwałości, gdyż w typowych aplikacjach warstwowych działajako klient warstwy trwałości. Niektóre proste aplikacje niezbyt dobrze separująlogikę biznesową od trwałości — nie będziemy się tym jednak zajmować, bo zale-cane podejście przedstawia rysunek.

Rysunek 2.1. Wysokopoziomowy przegląd interfejsów programistycznychHibernate z uwzględnieniem architektury warstwowej

Interfejsy Hibernate przedstawione na rysunku 2.1 można podzielić następująco:


Interfejsy wywoływane przez aplikacje w celu wykonania prostych operacjiCRUD i wyszukiwania. Interfejsy te stanowią główny punkt styku logikibiznesowej z Hibernate. Zawierają interfejsy: Session, Transaction i Query.

Interfejsy wywoływane przez kod infrastruktury aplikacji w celu konfiguracjiHibernate. Jest to przede wszystkim klasa Configuration.

Interfejsy wywołań zwrotnych pozwalające aplikacji reagować na zdarzeniazachodzące wewnątrz Hibernate. Są to interfejsy: Interceptor, Lifecyclei Validatable.

Interfejsy zapewniające rozszerzanie rozbudowanej funkcjonalnościodwzorowania w Hibernate. Są to interfejsy: UserType, CompositeUserTypei IdentifierGenerator. Interfejsy te implementuje kod infrastrukturyaplikacji (jeśli to konieczne).

Hibernate wykorzystuje istniejące interfejsy programistyczne Javy, włączającw to JDBC, JTA (Java Transaction API) oraz JNDI (Java Naming and DirectoryInterface). JDBC zapewnia odpowiedni poziom abstrakcji funkcji wspólnych dlaróżnych systemów relacyjnych baz danych, co oznacza, że Hibernate potrafi sko-rzystać z dowolnej bazy danych ze sterownikiem JDBC. JNDI i JTA umożliwiająHibernate integrację z serwerami aplikacji J2EE.

W niniejszym podrozdziale nie będziemy omawiać szczegółowej semantykimetod interfejsów Hibernate. Zajmiemy się raczej podstawowymi rolami inter-fejsów. Większość interfejsów znajduje się w pakiecie net.sf.hibernate. Przyj-rzyjmy się pokrótce każdemu z nich.

2.2.1. Interfejsy podstawowe

Pięć interfejsów podstawowych pojawia się w niemal każdej aplikacji wykorzy-stującej Hibernate. Dzięki nim możliwe staje się pobieranie i zapamiętywanietrwałych obiektów oraz sterowanie transakcjami.

Interfejs Session

Interfejs Session to główny interfejs każdej aplikacji Hibernate. EgzemplarzeSession są lekkie — koszt ich utworzenia i zniszczenia bywa niewielki. Jest toniezwykle istotne, bo każda aplikacja cały czas tworzy i usuwa coraz to nowe sesje,prawdopodobnie przy każdym nowym żądaniu. Sesje Hibernate nie są bezpiecznewielowątkowo i z tego powodu należy tak projektować aplikację, by używać ichw danym momencie w tylko jednym wątku.

Znaczenie sesji Hibernate można opisać jako coś pomiędzy połączeniemi transakcją. Najprościej traktować sesję jako bufor lub kolekcję załadowanychobiektów powiązanych z jedną jednostką zadaniową. Hibernate potrafi wykryćzmiany w obiektach tej jednostki zadaniowej. Często interfejs Session nazywasię zarządcą trwałości, gdyż zapewnia dostęp do podstawowych operacji trwało-ści takich jak zapis i pobieranie obiektów. Warto podkreślić, że sesja Hibernatenie ma nic wspólnego z sesją warstwy połączenia internetowego, na przykład

2.2. Podstawy architektury Hibernate 57

z HttpSession. Gdy w książce używamy słowa sesja, mamy na myśli sesję Hiber-nate. Gdy mówimy o sesji użytkownika, mamy na myśli obiekt HttpSession.

Interfejs Session został dokładnie omówiony w podrozdziale 4.2.

Interfejs SessionFactory

Aplikacja pobiera egzemplarze Session z SessionFactory. W porównaniu z Sessionobiekt ten jest znacznie bardziej interesujący.

Interfejs SessionFactory pewnością nie jest lekki! Został zaprojektowanyz myślą o współdzieleniu przez wiele wątków aplikacji. Najczęściej na całą aplika-cję występuje tylko jeden obiekt SessionFactory tworzony w momencie jej ini-cjalizacji. Jeśli jednak aplikacja korzysta z kilku baz danych w połączeniu z Hiber-nate, potrzeba osobnego obiektu SessionFactory dla każdej bazy danych.

Obiekt SessionFactory buforuje wygenerowane polecenia SQL i inne meta-dane odwzorowania stosowane przez Hibernate w trakcie działania aplikacji.Dodatkowo buforuje dane, które zostały odczytane w jednej jednostce zadanio-wej i mogłyby przydać się w innej jednostce zadaniowej (ten drugi poziom bufo-rowania działa tylko wtedy, gdy odwzorowania klas i kolekcji sugerują jego użycie).

Interfejs Configuration

Obiekt Configuration służy do konfiguracji i uruchomienia Hibernate. Aplikacjaużywa egzemplarza Configuration do wskazania położenia dokumentów odwzo-rowań i właściwości specyficznych dla Hibernate. Podrozdział 2.3 ze średnimstopniem złożoności opisuje konfigurację systemu Hibernate.

Interfejs Transaction

Interfejs Transaction jest opcjonalny. Aplikacje Hibernate nie muszą z niego korzy-stać, jeśli chcą zarządzać transakcjami we własnym zakresie. Interfejs stara sięukryć szczegóły implementacji konkretnych mechanizmów transakcyjnych: JDBC,klasy UserTransaction z JTA lub nawet transakcji CORBA (Common Object Requ-est Broker Architecture). W ten sposób zapewnia aplikacji jednorodny sposób ichobsługi. Ułatwia to zachowanie przenośności aplikacji Hibernate między różnymiśrodowiskami wykonywania i kontenerami.

W niniejszej książce stosujemy interfejs Transaction. Został on dokładniewyjaśniony w rozdziale 5.

Interfejsy Query i Criteria

Interfejs Query umożliwia wysyłanie zapytań do bazy danych i sterowanie proce-sem ich wykonywania. Zapytania pisze się w języku HQL lub też w odpowied-nim dla danej bazy danych dialekcie SQL. Egzemplarz Query odpowiada za dowią-zanie parametrów zapytania, ograniczenie liczby zwracanych wyników i wykonaniezapytania.

Interfejs Criteria jest bardzo podobny. Umożliwia utworzenie i wykonanieobiektowych kryteriów wyszukiwania.


Aby tworzony kod był możliwie krótki, Hibernate dostarcza kilka skrótóww interfejsie Session, by móc w jednym wierszu wykonać zapytanie. W książcenie stosujemy tych skrótów — zawsze używamy interfejsu Query.

Egzemplarz Query jest lekki nie daje się zastosować poza egzemplarzem Session,dla którego powstał. Opis funkcji interfejsu Query znajduje się w rozdziale 7.

2.2.2. Interfejsy wywołań zwrotnych

Interfejsy wywołań zwrotnych umożliwiają aplikacji otrzymywanie powiadomień,gdy coś ciekawego stanie się ze sprawdzanym obiektem — na przykład zostaniezaładowany, zapisany lub usunięty. Aplikacje stosujące Hibernate nie muszą ko-rzystać z wywołań zwrotnych, ale niejednokrotnie przydają się one do tworzeniaogólnej funkcjonalności, na przykład automatycznego tworzenia zapisów audy-torskich.

Interfejsy Lifecycle i Validatable zapewniają trwałym obiektom reakcję nazdarzenia związane z własnym cyklem życia trwałego. Cykl życia ma nieroze-rwalny związek z operacjami CRUD obiektu. Zespół projektowy Hibernate byłpod silnym wpływem innych rozwiązań ORM posiadających podobne wywoła-nia zwrotne. Później zdano sobie sprawę, że kasy trwałości implementująceinterfejsy specyficzne dla Hibernate nie są najlepszym pomysłem, gdyż ich sto-sowanie utrudnia przenośność kodu. Ponieważ ich używanie obecnie nie jest zale-cane, nie są one szerzej opisywane w niniejszej książce.

Interfejs Interceptor wprowadzono, by aplikacje mogły przetwarzać wywo-łania zwrotne bez potrzeby wprowadzania implementacji interfejsów Hibernatedo klas trwałości. Implementacje interfejsu Interceptor wprowadza się do egzem-plarzy trwałych klas jako parametry. Przykład ich użycia pojawi się w rozdziale 8.

2.2.3. Typy

Podstawowym i niezwykle użytecznym elementem architektury jest sposób wyko-nania obiektu Type w Hibernate. Obiekt ten odwzorowuje typ Javy na typ kolumnytabeli bazy danych (w rzeczywistości typ może dotyczyć wielu kolumn). Wszystkietrwałe właściwości klas trwałych, włączając w to asocjacje, posiadają odpowiednityp Hibernate. Ten sposób obsługi czyni Hibernate wyjątkowo elastycznym i roz-szerzalnym.

Istnieje bogaty zbiór typów wbudowanych zawierający wszystkie typy podsta-wowej Javy oraz wiele klas ze standardowej biblioteki JDK, włączając w to typy:java.util.Currency, java.util.Calendar, byte[] i java.io.Serializable.

Co więcej, Hibernate obsługuje typy zdefiniowane przez użytkownika. Inter-fejsy UserType i CompositeUserType dają możliwość kreowania własnych typów.W ten sposób klasy wykorzystywane w wielu różnych aplikacjach, na przykładAddress, Name i MonetaryAmount udaje się obsłużyć wygodnie i elegancko. Własnetypy uważa się za jedną z najistotniejszych cech Hibernate. Zalecamy z nich korzy-stać w coraz to nowy sposób!

Szczegóły dotyczące typów Hibernate zostały omówione w podrozdziale 6.1.

2.3. Konfiguracja podstawowa 59

2.2.4. Interfejsy rozszerzeń

Większość funkcjonalności Hibernate można dostosować do własnych potrzeb,włączając w to wybór wbudowanych strategii. Gdy okazują się one niewystarcza-jące, Hibernate dopuszcza zastosowanie własnej implementacji przez zastoso-wanie odpowiedniego interfejsu. Możliwe rozszerzenia są następujące:

generacja klucza głównego (interfejs IdentifierGenerator), obsługa dialektu języka SQL (klasa abstrakcyjna Dialect), strategia buforowania (interfejsy Cache i CacheProvider), zarządzanie połączeniem JDBC (interfejs ConnectionProvider), zarządzanie transakcjami (interfejsy TransactionFactory, Transactioni TransactionManagerLookup),

strategia ORM (hierarchia interfejsów ClassPersister), strategia dostępu do właściwości (interfejs PropertyAccessor), tworzenie pośredników (interfejs ProxyFactory).

Hibernate zawiera co najmniej jedną implementację każdego z wymienionychinterfejsów, więc najczęściej nie trzeba zaczynać od podstaw, gdy chce się jedy-nie rozszerzyć pewną wbudowaną funkcjonalność. Co więcej, dostępny kod źró-dłowy stanowi doskonały przykład w sytuacji, gdy tworzy się własne rozwiązanie.

Zanim zacznie się tworzyć jakikolwiek kod związany z Hibernate, warto zadaćsobie następujące pytanie: w jaki sposób zmusić do działania obiekt Session?

2.3. Konfiguracja podstawowa

Przyjrzeliśmy się przykładowej aplikacji oraz podstawowym interfejsom Hiber-nate. Aby móc skorzystać z automatycznej trwałości, trzeba poznać sposób jejkonfiguracji. Hibernate udaje się tak skonfigurować, by działało poprawnie w nie-malże dowolnej aplikacji Javy i środowisku programistycznym. Na ogół jednakstosuje się go w dwu- lub trójwarstowych aplikacjach klient-serwer, przy czymHibernate zostaje wdrożony tylko po stronie serwera. Aplikacją kliencką najczę-ściej jest przeglądarka internetowa, ale zdarzają się również aplikacje SWT i Swing.Choć w książce skupiamy się na wielowarstwowych aplikacjach internetowych,przedstawiane opisy mają zastosowanie również w dowolnej innej architekturze,na przykład aplikacjach wiersza poleceń. Istotnym jest, by zrozumieć różnicęw konfiguracji Hibernate w środowisku zarządzanym i niezarządzanym.

Środowisko zarządzanie — tworzy pule zasobów, na przykład połączeńz bazą danych, i dopuszcza deklaratywne (w postaci metadanych) określaniezakresu transakcji oraz zasad bezpieczeństwa. Serwery aplikacji J2EE,na przykład JBoss, BEA WebLogic lub IBM WebSphere, implementująw Javie standardowe (zgodne z J2EE) środowisko zarządzane.

Środowisko niezarządzane — zapewnia proste zarządzanie współbieżnościądzięki puli wątków. Pojemnik serwletowy taki jak Jetty lub Tomcat


zapewnia niezarządzane środowisko serwerowe dla aplikacji internetowychpisanych w Javie. Samowystarczalne aplikacje kliencie i aplikacje wierszapoleceń również uważa się za niezarządzane. Środowiska te nie udostępniająautomatycznego zarządzania transakcjami i zasobami oraz nie zapewniająinfrastruktury bezpieczeństwa. Sama aplikacja zarządza połączeniamiz bazą danych i określa granice transakcji.

Hibernate stara się w sposób abstrakcyjny traktować środowisko, w którym przy-chodzi mu pracować. W środowisku niezarządzanym sam obsługuje transakcjei połączenia JDBC (lub deleguje ich wykonanie do odpowiedniego kodu apli-kacji). W środowisku zarządzanym integruje się z transakcjami i połączeniamibazodanowymi zarządzanymi przez kontener. Hibernate potrafi poprawnie dzia-łać w obu środowiskach.

W obu środowiskach pierwszym zadaniem jest uruchomienie Hibernate.W praktyce nie jest to trudne — wystarczy utworzyć obiekt SessionFactory,używając klasy Connection.

2.3.1. Tworzenie obiektu SessionFactory

Aby uzyskać obiekt SessionFactory, należy najpierw utworzyć pojedynczy egzem-plarz klasy Configuration w momencie inicjalizacji aplikacji i skonfigurowaćścieżki do plików odwzorowań. Po konfiguracji obiekt Configuration pozwalatworzyć egzemplarze SessionFactory. Po ich wykonaniu obiekt Configurationstaje się zbędny.

Poniższy kod uruchamia Hibernate:

Configuration cfg = new Configuration();cfg.addResource("hello/Message.hbm.xml");cfg.setProperties(System.getProperties());SessionFactory sessions = cfg.buildSessionFactory();

Lokalizację pliku odwzorowania, Message.hbm.xml, określa się względem pod-stawowej ścieżki klas aplikacji. Jeśli na przykład ścieżka klas jest aktualnym fol-derem, plik Message.hbm.xml musi znajdować się wewnątrz folderu hello. Plikiodwzorowania XML muszą znajdować się w ścieżce wyszukiwania klas. W przy-kładzie wykorzystujemy również właściwości systemowe maszyny wirtualnej, byustawić pozostałe opcje konfiguracyjne (można je inicjalizować wcześniej w samejaplikacji lub przy uruchamianiu systemu maszyny wirtualnej).

Łańcuchwywołańmetod

Tworzenie łańcuchów wywołań metod to styl programowania obsługiwanyprzez wiele interfejsów Hibernate. Jest on bardziej popularny w językuSmalltalk niż w Javie. Niektóre osoby uważają go za mniej czytelny i trud-niejszy do debugowania niż typowy styl programowania w Javie. W więk-szości sytuacji jest jednak wyjątkowo wygodny.

Większość programistów Javy tworzy metody ustawiające lub doda-jące zwracające typ void, czyli brak wartości. Język SmallTalk nie posiadatypy void, więc metody ustawiające lub dodające zwracają obiekt otrzy-mujący dane. Takie podejście umożliwia zmianę wcześniejszego koduna następujący.


SessionFactory sessions = new Configuration() .addResource("hello/Message.hbm.xml") .setProperties(System.getProperties()) .buildSessionFactory();

Zauważ, że nie potrzeba deklarować lokalnej zmiennej dla obiektu Confi-guration. Styl ten będzie stosowany w niektórych przykładach, ale gdy ktośgo nie lubi, nie wymuszamy jego stosowania. Jeśli ktoś go lubi, zalecamypisanie każdego wywołania metody w osobnym wierszu. W przeciwnymrazie znacznie trudniej testować utworzony kod debugerem.

Przyjęło się, że pliki odwzorowań Hibernate w formacie XML zapisuje się w pli-kach z rozszerzeniem .hbm.xml. Dodatkowo przyjęło się, by tworzyć osobny plikodwzorowania dla każdej klasy, zamiast umieszczać cały opis odwzorowań w jed-nym pliku (jest to możliwe, ale nie jest zalecane). Przedstawiony przykład „Witajświecie” stosuje tylko jedną klasę trwałości, ale załóżmy, że jest ich wiele i każdeodwzorowanie znajduje się w osobnym pliku. Gdzie należy umieścić pliki odwzo-rowań?

Dokumentacja Hibernate zaleca, by plik odwzorowania dla każdej klasy trwa-łości umieszczać w tym samym folderze co klasę. Przykładowo, plik odwzoro-wania dla klasy Message należy umieścić w folderze hello pod nazwą Message.hbm.xml. Dla innej klasy trwałej należałoby wykonać osobny plik odwzorowania.Zalecamy stosować się do przedstawionej sugestii. Monolityczne pliki metada-nych narzucane przez niektóre systemy szkieletowe, na przykład struts-config.xmlz Struts, są głównym czynnikiem powodującym powstanie hasła „piekło meta-danych”. Wiele plików odwzorowań wczytuje się, wielokrotnie wywołując metodęaddResource(). Ewentualnie, gdy programista stosuje się do przedstawionej powy-żej konwencji, może użyć metody addClass(), przekazując jako parametr klasętrwałą.

SessionFactory sessions = new Configuration().addClass(org.hibernate.auction.model.Item.class).addClass(org.hibernate.auction.model.Category.class).addClass(org.hibernate.auction.model.Bid.class).setProperties(System.getProperties()).buildSessionFactory();

Metoda addClass() zakłada, że nazwa pliku odwzorowania kończy się rozszerze-niem .hbm.xml i znajduje się w tym samym folderze co odwzorowywany plik klasy.

Przedstawimy tworzenie pojedynczego obiektu SessionFactory, ponieważtakie podejście występuje w aplikacjach najczęściej. Jeśli potrzebny jest kolejnyobiekt, bo na przykład istnieje kilka baz danych, cały proces powtarza się od nowa.W ten sposób zawsze istnieje jeden obiekt SessionFactory na bazę danych gotowydo tworzenia obiektów Session działających z tą bazą danych i zestawem odwzo-rowań klas.

Konfiguracja Hibernate to nie tylko wskazanie dokumentów odwzorowań.Trzeba również wskazać sposób uzyskania połączenia z bazą danych oraz określićzachowanie Hibernate w różnych sytuacjach. Mnogość dostępnych właściwościkonfiguracyjnych potrafi przytłoczyć (pełna ich lista znajduje się w dokumentacji


Hibernate). Na szczęście większość parametrów stosuje sensowne wartości do-myślne, więc najczęściej potrzeba zmienić tylko ich niewielką część.

Aby określić opcje konfiguracyjne, korzysta się z jednej z wymienionychtechnik.

Przekazuje się egzemplarz klasy java.util.Properties jako parametrmetody Configuration.setProperties().

Ustawia się właściwości systemowe za pomocą konstrukcji java-Dwłaściwość=wartość.

Umieszcza się w ścieżce wyszukiwania klas plik o nazwie hibernate.properties.

Dołącza się elementy <property> do pliku hibernate.cfg.xml znajdującegosię w ścieżce wyszukiwania klas.

Techniki pierwszą i drugą stosuje się naprawdę rzadko — jedynie w trakcie testówlub szybkiego prototypowania. Większość aplikacji potrzebuje stałego pliku konfi-guracyjnego. Oba pliki, hibernate.properties i hibernate.cfg.xml, pełną tę samąfunkcję — konfigurują Hibernate. Wybór pliku zależy tak naprawdę od własnychpreferencji co do składni właściwości. Możliwe jest nawet mieszanie obu techniki posiadanie osobnych ustawień dla środowiska testowego i wdrożeniowego. Przed-stawimy to zagadnienie w dalszej części rozdziału.

Bardzo rzadko stosowanym rozwiązaniem alternatywnym jest przekazywanieprzez aplikację obiektu Connection z JDBC w momencie tworzenia obiektu Sessiondzięki obiektowi SessionFactory (powstaje wtedy kod typu sessions.openSession(myConnection)). Opcja ta pozwala nie podawać w trakcie konfiguracji żadnychopcji związanych z połączeniem z bazą danych. Nie polecamy takiego podejściadla nowych aplikacji, które mogą skorzystać z infrastruktury połączeń bazodano-wych całego środowiska (na przykład wykorzystując pulę połączeń JDBC lub źró-dła danych serwera aplikacji).

Ze wszystkich opcji konfiguracyjnych najważniejsze są ustawienia połącze-nia bazodanowego. Różnią się w zależności od tego, czy stosuje się środowiskozarządzane czy niezarządzane. Z tego względu opis rozbijemy na dwa przypadki.Zacznijmy od środowiska niezarządzanego.

2.3.2. Konfiguracja w środowisku niezarządzanym

W środowisku niezarządzanym, na przykład kontenerze serwletów, aplikacjaodpowiada za uzyskanie połączeń JDBC. Hibernate jest częścią aplikacji, więcrównież może uczestniczyć w ich uzyskaniu. Plik konfiguracyjny informuje, w jakisposób Hibernate może uzyskać (lub utworzyć nowe) połączenia JDBC. Ogól-nie nie zaleca się tworzenia połączeń za każdym razem, gdy tylko chce się skorzy-stać z bazy danych. Aplikacja Javy powinna zatem używać puli połączeń JDBC.Istnieją trzy powody przemawiające ze stosowaniem puli:

Uzyskiwanie nowych połączeń jest kosztowne. Utrzymywanie wielu niewykorzystywanych połączeń jest kosztowne.


Tworzenie instrukcji przygotowanych dla niektórych sterownikówrównież jest kosztowne.

Rysunek 2.2 przedstawia rolę puli połączeń JDBC w środowisku wykonawczymaplikacji internetowej. Ponieważ samo środowisko nie udostępnia puli połączeńbazodanowych, aplikacja musi wprowadzić własny algorytm tworzenia puli lubstosować w tym celu niezależną bibliotekę, na przykład udostępnianą na zasadachopen source bibliotekę C3P0. Aplikacje bez Hibernate najczęściej wywołujemetody puli połączeń, by uzyskać połączenie JDBC i wykonać polecenie SQL.

Rysunek 2.2. Pula połączeń JDBC w środowisku niezarządzanym

Po dodaniu Hibernate schemat ulega zmianie — ORM działa jako klient pulipołączeń JDBC, co przedstawia rysunek 2.3. Kod aplikacji używa interfejsówprogramistycznych Session i Query z Hibernate do wykonywania operacji trwało-ści danych. Zajmuje się również zarządzaniem transakcjami, używając interfejsuTransaction z Hibernate.

Rysunek 2.3. Hibernate z pulą połączeń w środowisku niezarządzanym

Wykorzystanie puli połączeń

Hibernate stosuje architekturę modułów rozszerzających, więc potrafi zintegro-wać się z dowolną pula połączeń. Obsługa C3P0 została wbudowana, więc z niejskorzystamy. Hibernate same utworzy pulę po podaniu wymaganych parametrów.Przykład pliku hibernate.properties stosującego C3P0 przedstawia listing 2.4.


Listing 2.4. Plik hibernate.properties z ustawieniami puli połączeń C3P0

hibernate.connection.driver_class = org.postgresql.Driverhibernate.connection.url = jdbc:postgresql://localhost/auctiondbhibernate.connection.username = auctionuserhibernate.connection.password = secrethibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialecthibernate.c3p0.min_size=5hibernate.c3p0.max_size=20hibernate.c3p0.timeout=300hibernate.c3p0.max_statements=50hibernate.c3p0.idle_test_period=3000

Przedstawiony fragment pliku określa następujące informacje omawiane wierszpo wierszu:

Nazwę klasy Javy implementującej sterownik JDBC dla konkretnej bazydanych (klasa Driver). Plik JAR sterownika musi znajdować w ścieżcewyszukiwania klas aplikacji.

Adres URL w formacie JDBC określający adres serwera i nazwę bazydanych dla połączeń JDBC.

Nazwa użytkownika bazy danych. Hasło do bazy danych dla wskazanego użytkownika. Klasa dialektu języka SQL. Pomimo wysiłków standaryzacyjnychorganizacji ANSI język SQL został zaimplementowany inaczej przezposzczególnych twórców baz danych. Należy więc określić klasę Dialektdla stosowanych połączeń. Hibernate zawiera wbudowaną obsługęnajpopularniejszych baz danych SQL. Nowe dialekty można łatwododawać.

Minimalna liczba oczekujących na działania połączeń JDBC utrzymywanaprzez C3P0.

Maksymalna liczba połączeń w puli. Zostanie zgłoszony wyjątek wykonania,gdy wartość ta okaże się niewystarczająca.

Okres bezczynności podawany w sekundach, więc w przykładzie jest to5 minut. Po tym okresie nieużywane połączenie zostaje usunięte z puli.

Maksymalna liczba zbuforowanych poleceń przygotowanych. Buforowaniepoleceń przygotowanych pozwala znacząco zwiększyć szybkość działaniaHibernate.

Czas bezczynności w sekundach, po którym połączenie jest automatyczniepoddawane walidacji.

Określanie właściwości w postaci hinernate.c3p0.* powoduje automatyczne wy-branie C3P0 jako rozwiązania puli połączeń dla Hibernate (nie potrzeba żadnejdodatkowej opcji w celu włączenia C3P0). Biblioteka C3P0 ma znacznie więcejfunkcji i opcji niż zostało przedstawionych w przykładzie. Zalecamy zajrzeć dodokumentacji interfejsu programistycznego Hibernate. Dokumentacja dla klasy


net.sf.hibernate.cfg.Environment informuje o wszystkich właściwościach kon-figuracyjnych, włączając w to opcje C3P0 i innych puli połączeń obsługiwanychw sposób bezpośredni przez Hibernate.

Pozostałymi obsługiwanymi pulami połączeń są: Apache DBCP i Proxool.Warto wypróbować we własnym środowisku wszystkie trzy rozwiązania przedpodjęciem decyzji. Społeczność Hibernate najczęściej wybiera C3P0 i Proxool.

Hibernate zawiera dodatkowo własny mechanizm puli połączeń, ale nadajesię on jedynie do testów i eksperymentów z Hibernate — nie należy go stoso-wać w systemie produkcyjnym. Nie był projektowany z uwzględnieniem wydaj-nej obsługi wielu współbieżnych żądań. Brakuje mu również funkcji wykrywa-nia niepowodzeń istniejących w wyspecjalizowanych pulach połączeń.

Uruchamianie Hibernate

W jaki sposób uruchomić Hibernate z przedstawionymi właściwościami? Jeśliwłaściwości zadeklaruje się w pliku hibernate.properties, wystarczy umieścić tenplik w ścieżce wyszukiwania klas aplikacji. Zostanie automatycznie wykryty i wczy-tany przez Hibernate w momencie tworzenia obiektu Configuration.

Podsumujmy poznane do tej pory kroki konfiguracyjne. Najwyższy czaspobrać i zainstalować Hibernate, jeśli chce się go użyć w środowisku niezarzą-dzanym.

1. Pobierz i rozpakuj sterownik JDBC dla bazy danych. Najczęściej jestdostępny na witrynie producenta bazy danych. Umieść plik JAR w ścieżcewyszukiwania klas aplikacji. To samo zrób z plikiem JAR Hibernate.

2. Dodaj zależności Hibernate do ścieżki wyszukiwania klas. Są one dołączonedo Hibernate w folderze lib. Warto zajrzeć do pliku lib/README.txt,by poznać listę wymaganych i opcjonalnych bibliotek.

3. Wybierz pulę połączeń JDBC obsługiwaną przez Hibernate i skonfiguruj ją,używając pliku właściwości. Nie zapomnij o wskazaniu dialektu języka SQL.

4. Niech klasa Configuration potrafi odnaleźć plik właściwości. Nadaj munazwę hibernate.properties i umieść go w ścieżce wyszukiwania klas.

5. Utwórz egzemplarz klasy Configuration w aplikacji i załaduj plikiodwzorowania w formacie XML, używając metod addResource() lubaddClass(). Utwórz obiekt SessionFactory na podstawie Configuration,wywołując metodę buildSessionFactory().

Niestety, obecnie nie są zdefiniowane żadne pliki odwzorowań. Jeśli chcesz, mo-żesz skorzystać z przykładu „Witaj świecie” lub pominąć pozostałą część tegorozdziału i przejść do rozdziału 3. omawiającego klasy trwałości oraz odwzoro-wania. Czytaj dalej, jeśli chcesz poznać konfigurację Hibernate w środowiskuzarządzanym.


2.3.3. Konfiguracja w środowisku zarządzanym

Środowisko zarządzane zajmuje się kilkoma najczęściej potrzebnymi zagadnie-niami, na przykład bezpieczeństwem aplikacji (uwierzytelnianie i autoryzacja),pulami połączeń i zarządzaniem transakcjami. Typowym środowiskiem zarzą-dzanym jest serwer aplikacji J2EE. Choć serwery aplikacji najczęściej projektujesię do obsługi EJB, można skorzystać z wielu udostępnianych przez nie usługi,nawet jeśli nie stosuje się ziarenek encyjnych EJB.

Hibernate najczęściej stosuje się w połączeniu z EJB sterowanym sesyjnielub przez komunikaty, co przedstawia rysunek 2.4. EJB wykorzystuje te sameinterfejsy Hibernate co serwlet, JSP lub samowystarczalna aplikacja: Session,Transaction i Query. Kod dotyczący Hibernate można bez problemów przenosićmiędzy środowiskami zarządzanymi i niezarządzanymi. Sam system w niewi-doczny sposób zajmuje się różnymi strategiami połączeń i transakcji.

Rysunek 2.4. Hibernate w środowisku zarządzanym przez serwer aplikacji

Serwer aplikacji udostępnia pulę połączeń jako źródło danych dowiązywanedzięki JNDI — egzemplarz javax.jdbc.Datasource. Należy poinformować Hiber-nate, gdzie ma szukać źródła danych w JNDI, podając pełną nazwę JNDI. Listing2.5 przedstawia przykład pliku konfiguracyjnego dla wspomnianej sytuacji.

Listing 2.5. Przykładowy plik hibernate.properties dla źródła danychzapewnianego przez kontener

hibernate.connection.datasource = java:/comp/env/jdbc/AuctionDBhibernate.transaction.factory_class =net.sf.hibernate.transaction.JTATransactionFactoryhibernate.transaction.manager_lookup_class = \ net.sf.hibernate.transaction.JBossTransactionManagerLookuphibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect

Plik najpierw podaje nazwę JNDI źródła danych. Źródło danych należy skonfi-gurować w deskryptorze wdrożenia aplikacji J2EE — sposób ustawiania zależyod dostawcy serwera aplikacji. Następnie włączona zostaje integracja Hibernate


z JTA. W następnym wierszu wskazujemy Hibernate lokalizację klasy Transac-tionManager serwera aplikacji, by zapewnić pełną integrację z transakcjami kon-tenera. Standard J2EE nie definiuje jednego konkretnego podejścia, ale Hiber-nate zawiera wbudowaną obsługę wszystkich popularnych serwerów aplikacji. Nakońcu ponownie pojawia się informacja o dialekcie języka SQL.

Po poprawnej konfiguracji wszystkich elementów sposób korzystania z Hiber-nate w środowisku zarządzanym nie różni się znacząco od korzystania z wersjiniezarządzanej — tworzy się obiekt Configuration z odwzorowaniami i na jegopodstawie tworzy obiekt SessionFactory. Dodatkowej uwagi wymagają ustawie-nia związane z transakcyjnością środowiska.

Java ma standardowy interfejs programistyczny dla transakcji, JTA, który służydo sterowania transakcjami w zarządzanym środowisku J2EE. Są to tak zwanetransakcje zarządzane przez kontener (CMT — Container Managed Transac-tion). Jeśli menedżer transakcji JTA występuje, połączenia JDBC są z nim zwią-zane i są pod jego pełną kontrolą. W środowisku niezarządzanym sytuacja jestzupełnie inna, ponieważ aplikacja (lub pula) bezpośrednio zarządza połączeniamii transakcjami JDBC.

Zarządzane i niezarządzane środowiska stosują inne podejście do transakcji.Ponieważ Hibernate w miarę możliwości chce zapewnić przenośność międzyoboma środowiskami, sam definiuje interfejs programistyczny do sterowania trans-akcjami. Interfejs Transaction z Hibernate stanowi abstrakcję ukrywającą róż-nice między transakcjami JTA i JDBC (a nawet transakcjami CORBA). Konkretnąstrategię transakcyjną ustawia właściwość hibernate.connection.factory_ class.Przyjmuje ona jedną z dwóch wartości:

net.sf.hibernate.transaction.JDBCTransactionFactory, która delegujewykonanie zadań do transakcji JDBC; strategię tę stosować należy z pulamipołączeń w środowisku niezarządzanym (staje się domyślna, gdy nie określisię żadnej strategii).

net.sf.hibernate.transaction.JTATransactionFactory, która delegujewykonanie zadań do transakcji JTA; jest to poprawna strategia dla CMT,gdzie połączenia są powiązane z JTA. Warto pamiętać, że jeśli właśnietrwa transakcja JTA w momencie wywołania beginTransaction(), kolejnezadania zostają wykonane w tej transakcji (w przeciwnym razie powstajenowa transakcja JTA).

Bardziej szczegółowe wprowadzenie do interfejsu programistycznego Transactioni wpływu wybranych scenariuszy transakcji zostało opisane w podrozdziale 5.1.Należy pamiętać o dwóch krokach koniecznych do przeprowadzenia w serwerzeaplikacji J2EE: ustawieniu klasy fabryki dla interfejsu programistycznego Tran-saction na JTA w opisany wcześniej sposób i zadeklarowaniu wyszukiwania me-nedżera transakcji w sposób specyficzny dla serwera aplikacji. Strategia wyszuki-wania potrzebna jest tylko wtedy, gdy korzysta się w Hibernate z buforowaniadwupoziomowego. Nie zaszkodzi ustawiać jej także wtedy, gdy nie używa siętakiego buforowania.


Hiberntez serweremTomcat

Tomcat nie jest pełnym serwerem aplikacji, ale kontenerem serwletów.Z drugiej strony zawiera pewne funkcje spotykane tylko w serwerachaplikacji. Hibernate może skorzystać z jednej z tych dodatkowych fun-kcji — puli połączeń Tomcata. Tomcat wewnętrznie korzysta z puli po-łączeń DBCP, ale udostępnia ją jako źródło danych JNDI (podobnie jakserwery aplikacji). Aby skonfigurować źródło danych Tomcata, dokonajedycji pliku server.xml zgodnie z instrukcjami podanymi w dokumentacjiJNDI/JDBC Tomcata. Hibernate odnajdzie źródło danych po ustawie-niu właściwości hibernate.connection.datasource. Warto pamiętać, żeTomcat nie zawiera menedżera transakcji, więc cała sytuacja jest nadajbardziej podobna do środowiska niezarządzanego.

W tej chwili powinieneś mieć działający system Hibernate, niezależnie od tego, czyużywasz prostego kontenera serwletów czy serwera aplikacji. Utwórz i skompilujklasę trwałości (na przykład klasę Message z początku rozdziału), skopiuj Hibernatei wymagane przez niego biblioteki do ścieżki wyszukiwania klas aplikacji wrazz plikiem hibernate.properties. Na końcu utwórz obiekt SessionFactory.

Kolejny podrozdział opisuje zaawansowane opcje konfiguracyjne Hibernate.Niektóre z nich polecamy. W szczególności możliwość tworzenia dla celów testo-wych dziennika wykonanych poleceń SQL lub stosowania wygodnych plikówkonfiguracyjnych XML zamiast prostych plików tekstowych. Można bezpieczniepominąć kolejny podrozdział i powrócić do niego dopiero po zdobyciu w roz-dziale 3. szczegółowej wiedzy na temat klas trwałych.

2.4. Zaawansowane ustawienia konfiguracyjne

Gdy aplikacja z Hibernate działa poprawnie, warto zainteresować się wszystkimiparametrami konfiguracyjnymi Hibernate. Dzięki nim nierzadko udaje się zopty-malizować działanie Hibernate, w szczególności przez odpowiednie dostrojeniewspółpracy z JDBC (na przykład zastosowanie aktualizacji wsadowych JDBC).

Nie chcemy na razie przynudzać wszystkimi szczegółami — najlepszym źró-dłem informacji na temat wszystkich opcji konfiguracyjnych jest dokumentacjaHibernate. W poprzednim podrozdziale przedstawiliśmy jedynie opcje pozwala-jące uruchomić aplikację.

Istnieje pewien parametr, na który już w tym momencie musimy kłaść dużynacisk. Przydaje się wielokrotnie, gdy tworzy się oprogramowanie. Ustawieniewłaściwości hibernate.show_sql na wartość true włącza wyświetlanie wszyst-kich utworzonych poleceń SQL na konsoli. Warto korzystać z tej opcji w momen-cie poszukiwania błędów, poszukiwania wąskiego gardła lub po prostu analizydziałania Hibernate. Warto wiedzieć, czym tak naprawdę zajmuje się warstwaORM, więc system nie ukrywa szczegółów poleceń SQL przed programistą.

Do tej pory zakładaliśmy przekazywanie parametrów konfiguracyjnych dziękiplikowi hibernate.properties lub programowo dzięki egzemplarzowi java.util.Properties. Trzecie z rozwiązań polega na użyciu pliku konfiguracyjnego w for-macie XML.

2.4. Zaawansowane ustawienia konfiguracyjne 69

2.4.1. Konfiguracja bazująca na pliku XML

Warto użyć pliku konfiguracyjnego XML (patrz listing 2.6), by w pełni skonfi-gurować obiekt SessionFactory. W odróżnieniu od pliku hibernate.properties,który zawiera tylko parametry konfiguracyjne, plik hibernate.cfg.xml może rów-nież określać lokalizacje dokumentów odwzorowań. Wiele osób preferuje centra-lizację konfiguracji Hibernate właśnie w ten sposób, by uniknąć dodawania para-metrów do obiektu Configuration w kodzie aplikacji.

Listing 2.6. Przykładowy plik konfiguracyjny hibernate.cfg.xml

?xml version='1.0'encoding='utf-8'?><!DOCTYPE hibernate-configurationPUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"><hibernate-configuration> <session-factory name="java:/hibernate/HibernateFactory"> <property name="show_sql">true</property> <property name="connection.datasource"> java:/comp/env/jdbc/AuctionDB </property> <property name="dialect"> net.sf.hibernate.dialect.PostgreSQLDialect </property> <property name="transaction.manager_lookup_class"> net.sf.hibernate.transaction.JBossTransactionManagerLookup </property> <mapping resource="auction/Item.hbm.xml"/> <mapping resource="auction/Category.hbm.xml"/> <mapping resource="auction/Bid.hbm.xml"/>< /session-factory></hibernate-configuration>

Deklaracja typu dokumentu pomaga analizatorowi XML dokonać walidacjidokumentu, czyli sprawdzić zgodność jego formatu z wytycznymizawartymi w DTD pliku konfiguracyjnego Hibernate.Opcjonalny atrybut name jest równoważny właściwości hibernate.ses-sion_factory_name. Służy do dowiązania JNDI dla SessionFactory,co zostanie omówione w dalszej części rozdziału.Właściwości hibernate można określać bez przedrostka hibernate.Poza tym przedrostkiem nazwy i wartości są dokładnie takie same jak wewłaściwościach ustawianych programowo.Dokumenty odwzorowań określa się jako zasoby aplikacji lub nawet jakona stałe zakodowane nazwy plików. Pliki użyte w przykładzie pochodząz aplikacji systemu akcyjnego opisywanego w rozdziale 3.

Do inicjalizacji Hibernate wystarczy teraz użycie następującego kodu:

SessionFactory sessions = new Configuration() .configure().buildSessionFactory();


Chwileczkę — skąd Hibernate wie, gdzie znajduje się plik konfiguracyjny?W momencie wywołania metody configure() Hibernate poszukuje pliku

o nazwie hibernate.cfg.xml w ścieżce wyszukiwania klas. Jeśli chce się dla plikukonfiguracyjnego zastosować inną nazwę lub też plik znajduje się w niestandar-dowej lokalizacji, do metody configure() należy przekazać ścieżkę.

SessionFactory sessions = new Configuration() .configure("/hibernate-config/auction.cfg.xml") .buildSessionFactory();

Stosowanie plików konfiguracyjnych okazuje się bardziej wygodne od plikówwłaściwości lub programowego ustawiania opcji. Możliwość usunięcia z kodulokalizacji plików odwzorowań klas (nawet jeśli miałby się znaleźć w pomocni-czej klasie inicjalizującej) stanowi ogromną zaletę przedstawionego podejścia.Nic nie stoi na przeszkodzie, by stosować różne zbiory plików odwzorowań (i inneopcje konfiguracyjne) w zależności od bazy danych i środowiska (produkcyjnegolub testowego). Co więcej, można je przełączać programowo.

Jeśli ścieżka wyszukiwania klas zawiera pliki hibernate.properties i hibernate.cfg.xml, ustawienia występujące w pliku XML nadpiszą ustawienia z pliku wła-ściwości. Rozwiązanie bywa użyteczne, gdy pewne podstawowe ustawienia trzy-ma się w pliku właściwości i modyfikuje dla każdego wdrożenia plikiem XML.

Warto zwrócić uwagę na nadanie parametru name dla obiektu SessionFactoryw pliku konfiguracyjnym XML. Hibernate używa tej nazwy do automatycznegodowiązania obiektu do JNDI po jego utworzeniu.

2.4.2. Obiekt SessionFactory dowiązany do JNDI

W większości aplikacji stosujących Hibernate obiekt SessionFactory powinienzostać utworzony tylko jeden raz w momencie inicjalizacji aplikacji. Cała apli-kacja powinna stosować ten pojedynczy egzemplarz — wszystkie obiekty Sessionnależy tworzyć na jego podstawie. Często pojawia się pytanie, gdzie umieścićobiekt fabryki, by był bez trudu dostępny z każdego miejsca aplikacji.

W środowisku J2EE obiekt SessionFactory warto dowiązać do JNDI, byłatwo udostępnić go wielu wątkom i komponentom wykorzystującym Hibernate.Oczywiście JNDI to nie jedyny sposób, w jaki komponenty aplikacji mogą uzy-skać obiekt SessionFactory. Istnieje wiele możliwych implementacji wzorca reje-stru, włączając w to użycie obiektu ServletContext lub zmiennej static finalw obiekcie singletonu. Szczególnie eleganckim wydaje się być rozwiązanie sto-sujące komponent szkieletowy odwrócenia sterowania (IoC — Inversion of Con-trol) o zasięgu całej aplikacji. JNDI jest popularnym rozwiązaniem udostępnianymjako usługi JMX, co wkrótce pokażemy. Niektóre alternatywy przedstawimyw podrozdziale 8.1.

Obiekt SessionFactory automatycznie dowiąże się do JNDI, gdy właściwośćhibernate.session_factory_name będzie zawierała nazwę węzła katalogu. Jeśliśrodowisko wykonawcze nie zapewnia domyślnego kontekstu JNDI (lub też do-myślna implementacja JNDI nie obsługuje egzemplarzy interfejsu Reference-


able), należy wskazać kontekst JNDI, używając właściwości hibernate.jndi.url i hibernate.jndi.class.

Uwaga Interfejs programistyczny JNDI umożliwia zapisywanie i odczyt obiektóww strukturze hierarchicznej (drzewiastej). JNDI implementuje wzorzecrejestru. Z JNDI można powiązać obiekty infrastruktury (konteksty trans-akcji, źródła danych), ustawienia konfiguracyjne (opcje środowiska, reje-stry użytkownika) lub nawet obiekty aplikacji (referencje do EJB, fabrykiobiektów).

Poniżej przedstawiamy przykładową konfigurację Hibernate, która dowiązujeobiekt SessionFactory do nazwy hibernate/HibernateFactory, wykorzystując bez-płatną implementację JNDI firmy Sun (fscontext.jar) bazującą na systemie plików.

hibernate.connection.datasource = java:/comp/env/jdbc/AuctionDBhibernate.transaction.factory_class =net.sf.hibernate.transaction.JTATransactionFactoryhibernate.transaction.manager_lookup_class = \net.sf.hibernate.transaction.JBossTransactionManagerLookuphibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialecthibernate.session_factory_name = hibernate/HibernateFactoryhibernate.jndi.class = com.sun.jndi.fscontext.RefFSContextFactoryhibernate.jndi.url = file:/auction/jndi

Do określenia parametrów równie dobrze można skorzystać z pliku konfigura-cyjnego XML. Przykład jest mało realistyczny, bo większość serwerów aplika-cji udostępniających pule połączeń dzięki JNDI stosuje również implementa-cję JNDI z domyślnym kontekstem dopuszczającym zapis. Opisane podejściestosuje serwer JBoss, w którym można opuścić dwie ostatnie właściwości i określićtylko nazwę dla obiektu SessionFactory. Do inicjalizacji dowiązania wystarczywtedy wykonanie kodu Configuration().configure().buildSessionFactory().

Uwaga Tomcat zawiera wbudowany kontekst JNDI tylko do odczytu — niemożna w nim nic zapisać z poziomu aplikacji po uruchomieniu konteneraserwletów. Z tego powodu Hibernate nie potrafi skorzystać z tego kontek-stu — należy stosować pełną implementację kontekstu (wykorzystującwspomniany kontekst firmy Sun) lub wyłączyć dowiązanie JNDI dla obie-ktu SessionFactory przez pominięcie w konfiguracji właściwości session_factory_name.

Przyjrzyjmy się innym istotnym opcjom konfiguracyjnym Hibernate dotyczącymtworzenia dziennika operacji.

2.4.3. Dzienniki

Hibernate (i wiele innych implementacji ORM) wykonuje polecenia SQL w spo-sób asynchroniczny. Polecenie INSERT zazwyczaj nie jest wykonywane zaraz powywołaniu przez aplikację metody Session.save(). Podobnie polecenie UPDATE


nie wykona się od razu po wywołaniu Item.addBid(). Instrukcje SQL zostają wyko-nane na końcu transakcji. Takie zachowanie nazywa się zapisem opóźnionym.

Takie podejście znacząco utrudnia śledzenie i debugowanie kodu ORM.W teorii możliwe jest traktowanie przez aplikację systemu Hibernate jako czarnejskrzynki i ignorowanie jego zachowania. Aplikacja nie potrafi wykryć asynchro-niczności działań Hibernate (a przynajmniej nie bez posiłkowania się bezpo-średnimi wywołaniami JDBC). Gdy pojawiają się problemy, warto byłoby siędowiedzieć, co tak naprawdę wykonuje Hibernate i w jakiej kolejności. PonieważHibernate jest projektem typu open source, można przyjrzeć się jego kodowiźródłowemu. Czasem to naprawdę pomaga! Z drugiej strony z powodu asynchro-nicznego działania Hibernate przy jego debugowaniu łatwo się „stracić”. Zamiastkorzystać z debugera, lepiej użyć dziennika operacji.

Wspomnieliśmy wcześniej o parametrze konfiguracyjnym hibernate.show_sql,który warto włączyć za każdym razem, gdy pojawią się problemy. Czasem pole-cenia SQL nie wystarczają i trzeba sięgnąć głębiej.

Hibernate tworzy dziennik wszystkich interesujących operacji, używającbiblioteki commons-logging Apache. Jest to cienka warstwa abstrakcji kierującadane do biblioteki log4j Apache (jeśli plik log4j.jar znajduje się w ścieżce wyszu-kiwania klas) lub do systemu dziennika z JDK 1.4 (jeśli używa się Javy 1.4 lubnowsze i brakuje log4j). Zalecamy stosowanie log4j, gdyż jest bardziej rozwinięty,bardziej popularny i stale rozwijany.

Aby zobaczyć jakiekolwiek wyniki działania log4j, w ścieżce wyszukiwaniaklas potrzeba pliku log4j.properties (podobnie jak plików hibernate.propertiesi hibernate.cfg.xml). Poniższa przykładowa zawartość tego pliku powoduje wy-świetlanie wszystkich komunikatów na konsoli.

### kieruj komunikaty bezpośrednio na standardowe wyjście ###log4j.appender.stdout=org.apache.log4j.ConsoleAppenderlog4j.appender.stdout.Target=System.outlog4j.appender.stdout.layout=org.apache.log4j.PatternLayoutlog4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE}%5p %c{1}:%L - %m%n### opcje dziennika podstawowego ###log4j.rootLogger=warn, stdout### opcje dziennika Hibernate ###log4j.logger.net.sf.hibernate=info### uwzględniaj parametry dowiązań JDBC ###log4j.logger.net.sf.hibernate.type=info### uwzględniaj aktywność bufora poleceń przygotowanych ###log4j.logger.net.sf.hibernate.ps.PreparedStatementCache=info

Przy tej konfiguracji w trakcie działania systemu nie pojawi się zbyt wiele komu-nikatów. Wystarczy jednak zamienić wartość info na debug w kategorii log4j.logger.net.sf.hibernate, by poznać szczegóły działania Hibernate. Warto sięupewnić, że tego rodzaju konfiguracja nie trafi na serwer produkcyjny — zapisdo dziennika będzie wolniejszy od dostępu do bazy danych.

Konfiguracja zawiera się obecnie w trzech plikach: hibernate.properties, hiber-nate.cfg.xml i log4j.properties.


Istnieje jeszcze jeden sposób konfiguracji Hibernate, jeśli serwer aplikacjiobsługuje JMX (Java Management Extensions).

2.4.4. Java Management Extensions

Świat Javy pełen jest specyfikacji, standardów i ich implementacji. Stosunkowonowym i istotnym już od pierwszej wersji jest standard Java Management Exten-sions (JMX). Dotyczy on zarządzania komponentami systemowymi, a w zasadzieusługami systemu.

Gdzie w tym całym obrazie mieści się Hibernate? Gdy umieści się go na ser-werze aplikacji, korzysta z innych usług, na przykład zarządzania transakcjamii pulą połączeń z bazą danych. Dlaczego nie uczynić samego Hibernate zarzą-dzalną usługą, której mogą używać inne elementy systemu? Integracja z JMX czyniz Hibernate zarządzalny komponent JMX.

Specyfikacja JMX definiuje następujące komponenty: JMX MBean — komponent wielokrotnego użytku (najczęściejinfrastrukturalny), który udostępnia interfejs zarządzania (administracji),

kontener JMX — zapewnia uogólniony dostęp (lokalny lub zdalny)do MBean,

klient JMX (najczęściej uogólniony) — umożliwia administrację dowolnymMBean dzięki kontenerowi JMX.

Serwer aplikacji obsługujący JMX (na przykład JBoss) działa jak kontener JMX,umożliwiając konfigurację i inicjalizację komponentów MBean jako części pro-cesu uruchamiania serwera aplikacji. Można monitorować i administrować MBean,stosując konsolę administracyjną serwera aplikacji (działa jak klient JMX).

Komponent MBean daje się utworzyć jako usługę JMX, która nie tylko jestprzenośnia między różnymi serwerami aplikacji z wbudowaną obsługą JMX,ale również zapewnia wdrożenie w działającym systemie (tak zwane „wdrożeniena gorąca”).

Hibernate można administrować jako JMX MBean. Usługa JMX dopuszczainicjalizację Hibernate w momencie uruchamiania serwera aplikacji i sterowania(konfigurowania) go dzięki klientowi JMX. Z drugiej strony komponenty JMX niesą automatycznie zintegrowane z transakcjami zarządzanymi przez kontener. Z tegopowodu opcje konfiguracyjne z listingu 2.7 (deskryptor wdrożenia usługi w JBoss)wyglądają podobnie do ustawień Hibernate dla środowiska zarządzanego.

Listing 2.7. Deskryptor wdrożenia Hibernate jako JMX w JBoss — plikjboss-service.xml

<server><mbean code="net.sf.hibernate.jmx.HibernateService" name="jboss.jca:service=HibernateFactory, name=HibernateFactory"> <depends>jboss.jca:service=RARDeployer</depends> <depends>jboss.jca:service=LocalTxCM,name=DataSource</depends> <attribute name="MapResources"> auction/Item.hbm.xml, auction/Bid.hbm.xml


</attribute> <attribute name="JndiName"> java:/hibernate/HibernateFactory </attribute> <attribute name="Datasource"> java:/comp/env/jdbc/AuctionDB </attribute> <attribute name="Dialect"> net.sf.hibernate.dialect.PostgreSQLDialect </attribute> <attribute name="TransactionStrategy"> net.sf.hibernate.transaction.JTATransactionFactory </attribute> <attribute name="TransactionManagerLookupStrategy"> net.sf.hibernate.transaction.JBossTransactionManagerLookup </attribute> <attribute name="UserTransactionName"> java:/UserTransaction </attribute></mbean></server>

Usługa HibernateService zależy od dwóch innych usług JMX — service=RARDe-ployer i service=LocalTxCM,name=DataSource — znajdujących się w domenie usłu-gowej jboss.jca.

MBean dla Hibernate znajduje się w pakiecie net.sf.hibernate.jmx. Niestety,metody zarządzania cyklem życia JMX nie stanowią części specyfikacji JMX 1.0.Z tego powodu metody start() i stop() z HibernateService są specyficzne dlaserwera aplikacji JBoss.

Uwaga Jeśli jesteś zainteresowany zaawansowanymi użyciami JMX, warto zajrzećdo kodu serwera JBoss. Wszystkie usługi (nawet kontener EJB) z JBoss sązaimplementowane jako MBean i mogą być zarządzane dzięki interfej-sowi konsolowemu.

Zalecamy konfigurację Hibernate w sposób programowy (z zastosowaniem obiektuConfiguration) przez próbą jego uruchomienia jako usługa JMX. Niektóre funk-cje (na przykład wdrażanie na gorąco aplikacji z Hibernate) jest możliwe tylkoz JMX. Największą zaletą Hibernate działającego z JMX jest automatyczny roz-ruch. Nie trzeba ręcznie tworzyć obiektów Configuration i SessionFactory. Wy-starczy korzystać z obiektu SessionFactory przez JNDI zaraz po uruchomieniuHibernateService.

2.5. Podsumowanie 75

2.5. Podsumowanie

W rozdziale przyjrzeliśmy się Hibernate z nieco wyższego poziomu. Dodatkowoprzedstawiliśmy jego architekturę, stosując przykład „Witaj świecie”. Pokazali-śmy, jak konfigurować Hibernate w różnych środowiskach z zastosowaniem roz-maitych sposobów przekazywania konfiguracji, włączając w to JMX.

Interfejsy Configuration i SessionFactory to punkty początkowe dla aplikacjichcących używać Hibernate zarówno w środowisku zarządzanym, jak i nieza-rządzanym. Hibernate stosuje dodatkowe interfejsy programistyczne, na przykładinterfejs Transaction, by zakryć różnice środowisk i zapewnić przenośność kodutrwałości danych.

Hibernate można zintegrować z niemal dowolnym środowiskiem Javy: ser-wletem, apletem lub trójwarstwową aplikacją klient-serwer. Najważniejszymi ele-mentami konfiguracji Hibernate są: zasoby bazy danych (konfiguracja połączeń),strategie transakcyjne i oczywiście metadane odwzorowań zawarte w plikach XML.

Interfejsy konfiguracyjne Hibernate zostały tak zaprojektowane, by obsłużyćmożliwe dużo różnych sposobów użycia przy zachowaniu ich dużej zrozumiało-ści. Najczęściej jeden plik o nazwie hibernate.cfg.xml i jeden wiersz kodu w pro-gramie wystarczają do uruchomienia Hibernate.

Konfiguracja nie miałaby jednak większego sensu bez klas trwałych i doku-mentów odwzorowań. Kolejny rozdział został w całości poświęcony pisaniu i od-wzorowywaniu klas trwałych. Wkrótce się przekonasz, jak w rzeczywistych apli-kacjach dzięki nietrywialnemu odwzorowaniu obiektowo-relacyjnemu zapewnićtrwałość obiektów.

Documents

Hibernate w akcji