Frak na miarę wyroczni

część 3

Współpraca Tuxedo i Oracle przy pomocy XA

Marcin Jackowski

W poprzednich odcinkach podaliśmy podstawowe informacje o
monitorze transakcyjnym Tuxedo i opisaliśmy przykład prostej aplikacji
wykorzystującej tę technologię. Ostatnia cześć będzie poświęcona czynnościom
administracyjnym, niezbędnym przy codziennej eksploatacji takiej aplikacji,
związanym z jej uruchamianiem, nadzorowaniem i diagnostyką. Na deser wspomnimy o
optymalizacji protokołu XA, co wydaje się dość istotne w kontekście współpracy
Tuxedo z Oracle.

Startowanie i zamykanie aplikacji

Mając wszystkie potrzebne składniki prostej aplikacji:
programy serwera, klienta i zarządcy (tms_ora.exe), pliki konfiguracyjne
i definiujące dane oraz odpowiednie ustawienia w środowisku, możemy uruchomić
aplikację i sprawdzić jej działanie.

Polecenie tmboot -y startuje bez zbędnych potwierdzeń
kolejne procesy aplikacji.

d:tuxxaora>tmboot -y
Booting all admin and server processes in D:tuxxaoratuxconfig
INFO: BEA Tuxedo, Version 8.1
INFO: Serial #: 564052122638-1205340300430, Expiration 2006-12-12, Maxusers
100
INFO: Licensed to: BEA Evaluation Customer

Booting admin processes ...

exec BBL -A :
    process id=4040 ... Started.

Booting server processes ...

exec tms_oracle -A :
    process id=3788 ... Started.
exec tms_oracle -A :
    process id=2632 ... Started.
exec server -A :
    process id=4000 ... Started.
4 processes started.

Zależnie od podanych przełączników, poleceniem tmboot
można też startować instancje wskazanego serwera (-s) lub ich grupy (-g).
Główny serwer administracyjny BBL (Bulletin Board Liaison) uruchamia się
na każdej z maszyn aplikacji. Sam Bulletin Board oznacza dynamiczną
strukturę w pamięci dzielonej, w której znajdują się wszystkie informacje o
aktualnym stanie aplikacji.

Polecenie tmshutdown pełni rolę odwrotną – zamyka
wszystkie lub wybrane procesy aplikacji. Przełącznik -w
z parametrem specyfikującym liczbę sekund przydaje się w sytuacjach awaryjnych i
powoduje wysłanie sygnału SIGKILL do procesu nie dającego się zamknąć
normalnie w podanym czasie.

Na skróty do serwisu

W większych przedsięwzięciach tworzeniem aplikacji klienckiej
i serwisów zajmują się różne osoby, jeszcze ktoś inny może przeprowadzać testy.
W kontekście diagnostyki warto wspomnieć o przydatnym narzędziu dostępnym
standardowo w Tuxedo z poziomu systemu operacyjnego. Pozwala ono wykonać serwis
z zadanymi parametrami
i otrzymać wynik bez jakiegokolwiek udziału docelowego klienta, a więc np. zanim
będzie on gotowy.

ud32 i wud32 to nazwy poleceń, które wywołują
wskazany serwis i wypisują otrzymany zwrotnie bufor FML. Pierwszy z nich
odpowiada klientowi natywnemu, drugi zdalnemu. Mogą działać interakcyjnie, ale
najwygodniejszym sposobem ich użycia będzie zapisanie potrzebnych pól FML w
pliku tekstowym i skierowanie go jako wejścia ud32:

ud32 <in.txt >out.txt

Polecenie zapisze wynikowy bufor FML do pliku out.txt
pod warunkiem, że w pliku in.txt zapisano poprawne pola wraz z
wartościami oczekiwanymi przez wywoływany serwis. W naszym przykładzie można się
posłużyć następującym plikiem wejściowym:

SRVCNM SVC_GET_EMP
EMPNO 7788

Trzeba jednak pamiętać o separowaniu pól i wartości tylko
jedną tabulacją oraz zadbać, by system rozpoznał specjalne pole SRVCNM.
Aby tak się stało, można dopisać plik Usysfl32 do zmiennej FIELDTBLS32
albo jego zawartość włączyć do własnego zbioru definicji pól. W przypadku
aplikacji autoryzującej sesje klienckie nie ominie nas spełnienie wymogów w
postaci np. konta i hasła. To jednak wykracza poza ramy tego tekstu.

Diagnostyka

W diagnozowaniu problemów w działaniu aplikacji Tuxedo,
podstawową rolę odgrywa tzw. ULOG (User Log) czyli plik dziennika komunikatów.
Położenie i stałą cześć jego nazwy wyznacza parametr ULOGPFX pliku
konfiguracyjnego, np. ULOGPFX=”D:tuxxaoraULOG”.

Do niej dokleja się po kropce ciąg cyfr aktualnej daty (MMDDYY),
dzięki czemu o północy automatycznie powstaje nowy plik. Każda linia ULOG’u
rozpoczyna się podobnym ciągiem określającym czas danego wpisu, nazwę maszyny i
serwera. Do ULOG’u trafiają zapisy większości działań podejmowanych przez
system, a także jawnie wypisywanych przez kod przy pomocy funkcji userlog
(pod względem parametrów zgodnej z funkcją printf). Komunikaty systemowe
zostały skategoryzowane i ponumerowane (podobnie jak w Oracle), zaś dokumentacja
zawiera ich pełen wykaz. Przykładowy fragment dziennika ULOG:

194022.CYBERIUSZ!server.2724.2404.0: gtrid x0 x41a7606d x11: -- SVC_GET_EMP:
Pobrano ENAME=SCOTT, JOB=ANALYST, SAL=230,770000
194929.CYBERIUSZ!server.2724.2404.0: LIBTUX_CAT:522: INFO: Default tpsvrdone()
function used
194929.CYBERIUSZ!tms_oracle.2488.2632.0: CMDTUX_CAT:457: INFO: TMS tpsvrdone
complete
194929.CYBERIUSZ!tms_oracle.3756.2844.0: CMDTUX_CAT:457: INFO: TMS tpsvrdone
complete
194933.CYBERIUSZ!BBL.3396.268.0: CMDTUX_CAT:26: INFO: The BBL is exiting
system

Każdemu serwerowi można przypisać w konfiguracji dedykowane
pliki strumieni wyjściowego i diagnostycznego (domyślnie są to pliki wspólne dla
całej aplikacji).

Komunikaty diagnostyczne dotyczące styku zarządcy zasobu i
bazy Oracle znajdziemy w katalogu wskazanym przez LogDir w OPENINFO
danego serwera. W razie potrzeby powstają tam pliki o nazwach zawierających
datę, np. xa_NULL12122004.trc

W najnowszym z nich można znaleźć wyjaśnienie niektórych
przyczyn niepowodzenia uruchomienia tms_oracle, np.

ORACLE XA: Version 9.2.0.1.0. RM name = "Oracle_XA".
173514.3972:3312.0:
ORA-01017: invalid username/password; logon denied
MIB

Tuxedo oferuje też tzw. MIB (Management Information Base),
z której można odczytać informacje o wszystkich składnikach aplikacji, a także w
pewnym zakresie dokonywać ich modyfikacji. Pozwala na to specjalny serwis
systemowy o nazwie .TMIB. Rozpoznaje on pewną liczbę predefiniowanych pól
FML, poprzez które zleca się odpowiednią operację oraz jej zakres (np.
uruchomienie dodatkowej instancji serwera). Repertuar trzech operacji GET,
GETNEXT i SET jest podobny do mechanizmów SNMP. Na przykład, aby za pomocą
ud32
pobrać informacje
o pewnym serwerze, można wywołać serwis .TMIB. w następujący sposób:

SRVCNM .TMIB
TA_CLASS T_SERVER
TA_OPERATION GET
TA_SRVID 100

Obowiązkowe dla .TMIB. pola TA_OPERATION
i TA_CLASS zawierają odpowiednio operację i nazwę jednej z wielu klas,
które szczegółowo opisuje dokumentacja. Zależnie od nich podaje się też
najczęściej dodatkowe pola wskazujące zakres pobieranych danych lub określające
właściwości obiektu tworzonego lub modyfikowanego przez operację SET.

tmadmin

Podstawowym i zawsze dostępnym narzędziem administratora
aplikacji Tuxedo jest tmadmin. W trybie interakcyjnym, ten niezbyt
wyrafinowany interpreter poleceń, nie należy wprawdzie do najwygodniejszych, ale
zwykłym przekierowaniem wejścia i wyjścia daje się „sprząc” z plikami czy innymi
poleceniami umożliwiając tym samym administratorowi wygodną automatyzację
niejednej czynności.

Poleceniem psr (print servers) uzyskamy listę
serwerów
z takimi informacjami, jak dotychczasowa liczba wywołań (RqDone) i ich
„pracochłonność” (Load Done). Jeśli któryś z serwisów serwera aktualnie
pracuje, to jego nazwa pojawi się w ostatniej kolumnie (tu INQ).

> psr
Prog Name Queue Name  Grp Name IDRqDone Load Done Current Service
--------- ----------- -------- -------- ---- ---- ---------------
BBL.exe   55432       SITE1    0        1    50   ( IDLE )
inser.exe 00001.00010 GROUP1   10       6    300  INQ
deser.exe 00001.00020 GROUP1   20       0    0    ( IDLE )
upser.exe 00001.00030 GROUP1   30       9    450  ( IDLE )

Poleceniem psr (print services) uzyskamy listę
aktualnie dostępnych serwisów

> psc
Service Name Routine Name Prog Name Grp Name ID Machine # Done Status
------------ ------------ --------- -------- -- ------- ------ ------
INQ          Inq          inser.exe GROUP1   10 SITE1   5      AVAIL
DELETE       Delete       deser.exe GROUP1   20 SITE1   0      AVAIL
UPDATE       Update       upser.exe GROUP1   30 SITE1   9      AVAIL

Optymalizacje protokołu XA

Jak pamiętamy, protokół zatwierdzania w dwóch fazach (2PC)
obejmuje dwukrotną komunikację monitora z zasobami uczestniczącymi w
rozproszonej transakcji.
W pierwszej fazie każdy z nich otrzymuje „niezobowiązujące” zlecenie
zatwierdzenia, które może odrzucić. Dopiero, gdy wszyscy zagłosują na „tak”,
zarządca może rozesłać komunikat o ostatecznym, właściwym zatwierdzeniu. Do
czasu jego otrzymania zasoby nie zdradzają światu, że transakcja się dokonała.

Mamy więc do czynienia z wstrzymywaniem procesów
i skutków transakcji, zasoby odpowiadające szybko na fazę prepare to commit
muszą czekać, aż zrobi to także ostatni, być może reagujący znacznie wolniej
zasób. Takie narzuty czasowe bywają niekorzystne i aby im przeciwdziałać,
wprowadzono w Tuxedo możliwość sterowania trybem działania 2PC czy też jego
optymalizacji.

Służy temu parametr CMTRET podawany w sekcji
RESOURCES
pliku konfiguracyjnego aplikacji UBBconfig. Akceptuje on dwie
wartości COMPLETE (domyślnie)
i LOGGED. Pierwsza, jak nietrudno zgadnąć, odpowiada pełnemu wykonaniu
obydwu faz procedury 2PC. Sprzyja niezawodności, ale może skutkować opóźnieniami
przetwarzania, szczególnie gdy jakiś zasób odstaje od innych pod względem czasu
reakcji na commit. Druga zezwala monitorowi na zachowanie nieco bardziej
ryzykowne, ale za to znacznie poprawiające wydajność – inicjator transakcji
otrzymuje zwrotny sygnał jej zatwierdzenia już po pierwszej fazie, więc zyskuje
na czasie. Może się zdarzyć, że ten zaoszczędzony czas będzie jednak musiał
„oddać” czekając na blokadę zasobu, który zarządca zwolni dopiero po pełnej
drugiej fazie. Do takiej niezbyt prawdopodobnej, ale możliwej sytuacji może
dojść np. wtedy, gdy inicjator (po skończeniu pewnej transakcji) szybko
rozpocznie nową na tym samym rekordzie, który w bazie danych blokuje nie
skończona jeszcze poprzednia transakcja.

Drugi sposób optymalizacji transakcji rozproszonych można
zastosować, gdy któryś z uczestniczących zasobów nie uległ modyfikacji i de
facto nie ma czego zatwierdzać. Zgłasza on wówczas koordynatorowi ten fakt i
może być pominięty w negocjowaniu ostatecznego wyniku transakcji.

Nie każda aplikacja oparta na Tuxedo obejmuje większą liczbę
zasobów. Kiedy korzysta ona z tylko jednej bazy danych, nie ma potrzeby
przeprowadzania dwóch faz zatwierdzania. Tuxedo wykrywa takie przypadki i
automatycznie redukuje zatwierdzanie do jednej fazy.

Źródła

Pobieżna i wybiórcza prezentacja Tuxedo współpracującego z
Oracle pomija wiele kwestii, zwłaszcza dodatkowych możliwości, jakie oferuje ten
monitor transakcji. Zainteresowani mogą poszerzyć swoją wiedzę sięgając do
podanych niżej źródeł.

  1. The Tuxedo System: Software for Constructing and
    Managing Distributed Business Applications, Juan M. Andrade, Terence J.
    Dwyer, Stephen D. Felts, Mark T. Carges, Addison-Wesley, 1996, ISBN
    0-201-634937
  2. Distributed Transaction Processing: The XA
    Specification, X/Open Company Ltd. ISBN: 1 872630 24 3
  3. Relational Databases and Knowledge Bases, Gardarin
    G., Valduriez P., Addison-Wesley, 1988; ISBN 0-201-099551
  4. Global Transactions – X/Open XA – Resource Managers,
    Aurora Information Systems, Inc., 1998-2000
  5. BEA Tuxedo Programmer’s Guide, Version 9.0, BEA
    Systems, Inc. 2005
  6. Programming a BEA Tuxedo ATMI Application Using C,
    Version 9.0, BEA Systems, Inc. 2005
  7. Administering a BEA Tuxedo Application at Run Time,
    Version 9.0, BEA Systems, Inc., 2005
  8. Programming a BEA Tuxedo Application Using FML,
    BEA Systems, Inc., 2001
  9. BEA Tuxedo 8.0, ATMI [Introduction,
    Programming, Administration, Reference, Tutorials], dokumentacja
    hipertekstowa, BEA Systems, Inc. 2001
  10. BEA Tuxedo Command Reference, Release 8.1,
    January 2003
  11. Oracle8i Server Application Development, Release
    8.1.6, dokumentacja hipertekstowa, Oracle Corporation, 1999
    – Pro*C/C++ Precompiler Programmer’s Guide, 5.Advanced
    Topics; Developing X/Open Applications
    – Oracle8i Application Developer’s Guide –
    Fundamentals; Working with Transaction Monitors with Oracle XA
  12. XA-Server Integration Guide for TUXEDO, W.I.R.E.D. Information
    Products Sybase, Inc., [Publikacja dotyczy Sybase, ale wiele z jej treści da się
    uogólnić na zastosowania Tuxedo i XA z innymi produktami]