[ Pobierz całość w formacie PDF ]
do sterowania transakcjami w zarządzanym środowisku J2EE. Są to tak zwane
transakcje 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 jest
zupełnie inna, ponieważ aplikacja (lub pula) bezpośrednio zarządza połączeniami
i 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ędzy
oboma ś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 deleguje
wykonanie zadań do transakcji JDBC; strategię tę stosować należy z pulami
połączeń w środowisku niezarządzanym (staje się domyślna, gdy nie określi
się żadnej strategii).
net.sf.hibernate.transaction.JTATransactionFactory, która deleguje
wykonanie 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śnie
trwa transakcja JTA w momencie wywołania beginTransaction(), kolejne
zadania zostajÄ… wykonane w tej transakcji (w przeciwnym razie powstaje
nowa transakcja JTA).
Bardziej szczegółowe wprowadzenie do interfejsu programistycznego Transaction
i wpływu wybranych scenariuszy transakcji zostało opisane w podrozdziale 5.1.
Należy pamiętać o dwóch krokach koniecznych do przeprowadzenia w serwerze
aplikacji 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 buforowania
dwupoziomowego. Nie zaszkodzi ustawiać jej także wtedy, gdy nie używa się
takiego buforowania.
68 ROZDZIAA 2.
Wprowadzenie i integracja Hibernate
Hibernte
Tomcat nie jest pełnym serwerem aplikacji, ale kontenerem serwletów.
z serwerem
Z drugiej strony zawiera pewne funkcje spotykane tylko w serwerach
Tomcat
aplikacji. 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 zródło danych JNDI (podobnie jak
serwery aplikacji). Aby skonfigurować zródło danych Tomcata, dokonaj
edycji pliku server.xml zgodnie z instrukcjami podanymi w dokumentacji
JNDI/JDBC Tomcata. Hibernate odnajdzie zródło danych po ustawie-
niu właściwości hibernate.connection.datasource. Warto pamiętać, że
Tomcat nie zawiera menedżera transakcji, więc cała sytuacja jest nadaj
bardziej podobna do środowiska niezarządzanego.
W tej chwili powinieneś mieć działający system Hibernate, niezależnie od tego, czy
używasz prostego kontenera serwletów czy serwera aplikacji. Utwórz i skompiluj
klasę trwałości (na przykład klasę Message z początku rozdziału), skopiuj Hibernate
i wymagane przez niego biblioteki do ścieżki wyszukiwania klas aplikacji wraz
z 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ów
konfiguracyjnych XML zamiast prostych plików tekstowych. Można bezpiecznie
pominąć 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ę wszystkimi
parametrami konfiguracyjnymi Hibernate. Dzięki nim nierzadko udaje się zopty-
malizować działanie Hibernate, w szczególności przez odpowiednie dostrojenie
współpracy z JDBC (na przykład zastosowanie aktualizacji wsadowych JDBC).
Nie chcemy na razie przynudzać wszystkimi szczegółami najlepszym zró-
dłem informacji na temat wszystkich opcji konfiguracyjnych jest dokumentacja
Hibernate. 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ży
nacisk. Przydaje siÄ™ wielokrotnie, gdy tworzy siÄ™ oprogramowanie. Ustawienie
wł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 analizy
działania Hibernate. Warto wiedzieć, czym tak naprawdę zajmuje się warstwa
ORM, więc system nie ukrywa szczegółów poleceń SQL przed programistą.
Do tej pory zakładaliśmy przekazywanie parametrów konfiguracyjnych dzięki
plikowi 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'?>
[ Pobierz całość w formacie PDF ]