[ Pobierz całość w formacie PDF ]

Uwaga Tomcat zawiera wbudowany kontekst JNDI tylko do odczytu  nie
można w nim nic zapisać z poziomu aplikacji po uruchomieniu kontenera
serwletów. Z tego powodu Hibernate nie potrafi skorzystać z tego kontek-
stu  należy stosować pełną implementację kontekstu (wykorzystując
wspomniany 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Ä…cym
tworzenia 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 po
wywołaniu przez aplikację metody Session.save(). Podobnie polecenie UPDATE
72 ROZDZIAA
2.
Wprowadzenie i integracja Hibernate
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óz
nionym.
Takie podejście znacząco utrudnia śledzenie i debugowanie kodu ORM.
W teorii możliwe jest traktowanie przez aplikację systemu Hibernate jako czarnej
skrzynki 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
z
ródłowemu. Czasem to naprawdę pomaga! Z drugiej strony z powodu asynchro-
nicznego działania Hibernate przy jego debugowaniu łatwo się  stracić . Zamiast
korzystać 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ąc
biblioteki commons-logging Apache. Jest to cienka warstwa abstrakcji kierujÄ…ca
dane 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 lub
nowsze 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 wyszukiwania
klas potrzeba pliku log4j.properties (podobnie jak plików hibernate.properties
i 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.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.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  zapis
do 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.
2.4. Zaawansowane ustawienia konfiguracyjne 73
Istnieje jeszcze jeden sposób konfiguracji Hibernate, jeśli serwer aplikacji
obsługuje JMX (Java Management Extensions).
2.4.4. Java Management Extensions
Z
wiat Javy pełen jest specyfikacji, standardów i ich implementacji. Stosunkowo
nowym i istotnym już od pierwszej wersji jest standard Java Management Exten-
sions (JMX). Dotyczy on zarzÄ…dzania komponentami systemowymi, a w zasadzie
usł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 transakcjami
i 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 czyni
z Hibernate zarzÄ…dzalny komponent JMX.
Specyfikacja JMX definiuje następujące komponenty:
JMX MBean  komponent wielokrotnego użytku (najczęściej
infrastrukturalny), 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ę dowolnym
MBean 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 jest
przenoś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żenie
na gorÄ…ca ).
Hibernate można administrować jako JMX MBean. Usługa JMX dopuszcza
inicjalizacjÄ™ Hibernate w momencie uruchamiania serwera aplikacji i sterowania
(konfigurowania) go dzięki klientowi JMX. Z drugiej strony komponenty JMX nie
są automatycznie zintegrowane z transakcjami zarządzanymi przez kontener. Z tego [ Pobierz całość w formacie PDF ]