Podręcznik użytkownika

Korzystanie z produktu DB2 Connect i monitorów przetwarzania transakcji

W poprzedniej sekcji omówiono wykorzystanie produktu DB2 Connect z serwerami aplikacji. Serwer aplikacji umożliwia dużej liczbie użytkowników wykonywanie aplikacji przy użyciu minimalnych zasobów systemowych.

Serwer aplikacji można rozszerzyć w taki sposób, aby pozwalał na wywoływanie skoordynowanych transakcji z aplikacji wykonywanych przez serwer aplikacji. Taka koordynacja transakcji jest powszechnie znana jako monitor przetwarzania transakcyjnego (TP). Monitor TP działa w powiązaniu z serwerem aplikacji.

O transakcji można myśleć jak o procedurze zdarzenia, zazwyczaj żądaniu usługi uruchomionej w ramach normalnych, codziennych operacji wykonywanych w organizacji. Monitory TP zostały zaprojektowane do pracy, którą jest uporządkowane przetwarzanie transakcji.

W każdej organizacji są zasady i procedury opisujące sposób, w jaki organizacja ta powinna działać. Aplikacje użytkowników, w których zasady te zostały zaimplementowane, można nazywać logiką biznesową. Transakcje wykonywane przez takie aplikacje komercyjne bardzo często nazywamy przetwarzaniem transakcyjnym lub przetwarzaniem transakcyjnym w trybie z połączeniem (Online Transaction Processing - OLTP).

Kluczowe charakterystyki komercyjnego przetwarzania OLTP:

Wielu użytkowników
W przypadku przetwarzania transakcyjnego typowe jest współużytkowanie go w organizacji, ponieważ wiele osób wpływa na bieżący stan działalności gospodarczej.

Powtarzalność
Większa część współpracy z komputerem jest zwykle tym samym procesem, wykonywanym wielokrotnie. Na przykład wielokrotnie w ciągu dnia odbywa się wprowadzanie zamówień lub przetwarzanie płatności.

Krótkotrwałe operacje
Większa część pracy wykonywanej przez osoby zatrudnione w organizacji za pomocą systemu przetwarzania transakcyjnego to krótkotrwałe operacje.

Współużytkowanie danych
Może istnieć tylko jedna kopia tych danych, ponieważ dane reprezentują stan organizacji.

Spójność danych
Dane muszą reprezentować bieżący stan organizacji, dlatego też muszą być wewnętrznie spójne. Na przykład każde zamówienie musi być związane z konkretnym rekordem klienta.

Niski koszt transakcji
Koszt systemu powinien być minimalny, ponieważ przetwarzanie transakcyjne tworzy bezpośredni koszt funkcjonowania firmy. Produkt DB2 Connect umożliwia aplikacjom działającym pod kontrolą serwera aplikacji uruchomionego w systemie UNIX, Windows NT, Windows 2000 lub OS/2 wykonywanie transakcji skierowanych do serwerów baz danych znajdujących się w sieci LAN, na hoście lub w systemie AS/400 i ich koordynację za pomocą monitora przetwarzania transakcyjnego.

DB2 Connect Support dla monitorów przetwarzania transakcyjnego

Na tym rysunku zarówno interfejsy API, jak i mechanizm połączeń między serwerem aplikacji i serwerami baz danych postprocesora zapewniane są przez produkt DB2 Connect Enterprise Edition.

Przykłady monitorów TP

Do najbardziej popularnych monitorów przetwarzania transakcyjnego, dostępnych obecnie na rynku należą:

Microsoft Transaction Server Remote S/390, AS/400 i serwery baz danych sieci LAN mogą być używane wewnątrz transakcji koordynowanych przez te monitory TP.

Tuxedo i DB2 Connect

W przypadku produktu DB2 Connect wersja 6 i poprzednie aplikacje oparte na Tuxedo miały dostęp do serwerów baz danych hosta i systemu AS/400 ograniczony tylko do odczytu. Ograniczenie to nie istnieje w produkcie DB2 Connect wersja 7. Obecnie aplikacje oparte na Tuxedo mogą aktualizować serwery baz danych hosta i systemu AS/400 w ramach skoordynowanej transakcji Tuxedo. Mają zastosowanie specjalne ograniczenia i wymagania związane z konfiguracją. Więcej informacji można znaleźć w podręczniku Koncentrator połączeń DB2 Connect.

Model przetwarzania transakcji rozproszonych X/Open (DTP)

Do aktualizacji wielu zasobów w ramach jednej transakcji może być wymagana aplikacja wykonująca logikę biznesową. Na przykład aplikacja bankowa, w której zaimplementowane zostało przekazywanie pieniędzy z jednego konta na inne może wymagać debetowania jednej bazy danych (konta "skąd") i kredytowania drugiej bazy (konta "do").

Możliwe jest również, że dwie bazy danych pochodzą od innych dostawców. Na przykład jedna baza danych może być typu DB2 Universal Database for OS/390, a druga bazą danych Oracle. Zamiast monitorów, z których każdy implementuje interfejs transakcji prawnie zastrzeżony dla dostawcy bazy danych, zdefiniowany został jeden wspólny interfejs transakcji między monitorem TP i wszystkimi zasobami, do których sięga aplikacja. Interfejs ten jest znany pod nazwą interfejsu XA. Monitor TP korzystający z interfejsu XA nazywamy menedżerem transakcji zgodnym z XA. Zasób dający się aktualizować, w którym został zaimplementowany interfejs XA, nazywamy menedżerem zasobów zgodnym z XA.

Wszystkie monitory transakcji wymienione poniżej są zgodne z XA. Serwery baz danych zdalnego hosta, AS/400 i DB2 UDB w sieci lokalnej są RM zgodnymi z XA, gdy dostęp do nich następuje za pośrednictwem DB2 Connect. Dlatego też każdy monitor przetwarzania transakcyjnego, który ma menedżera transakcji zgodnego z XA, może w aplikacjach biznesowych wykonujących transakcje korzystać z serwerów baz danych hosta, systemu AS/400 i DB2 UDB w sieci lokalnej.

W jaki sposób korzystać z produktu DB2 Connect z menedżerem transakcji zgodnym z XA

W tej sekcji zostały opisane kroki konfiguracyjne niezbędne, aby móc korzystać z serwerów baz S/390 i AS/400 przy użyciu monitora przetwarzania transakcyjnego. Założono, że użytkownik ma działający monitor przetwarzania transakcyjnego oraz zainstalowany produkt DB2 Connect, jak również skonfigurowane i przetestowane połączenie z serwerem baz danych hosta lub systemu AS/400. Szczegółowe informacje można znaleźć w podręczniku Krótkie wprowadzenie do produktu DB2 Connect.

Kroki niezbędne do skonfigurowania większości popularnych monitorów przetwarzania transakcyjnego można znaleźć w podręczniku Administration Guide. Konfigurowanie dla serwera baz danych DB2 UDB w sieci LAN nie różni się od konfigurowania serwera baz danych hosta lub AS/400. Następujące instrukcje zawierają zarys kroków ogólnej konfiguracji dla monitorów przetwarzania transakcyjnego, które nie zostały wymienione w podręczniku Administration Guide.

Aby skonfigurować produkt DB2 Connect, tak aby w monitorze przetwarzania transakcyjnego móc korzystać z serwerów baz danych S/390 i AS/400, należy wykonać następujące czynności:

  1. Skonfigurować monitor przetwarzania transakcyjnego w taki sposób, aby miał dostęp do DB2 XA Switch. DB2 XA Switch udostępnia monitor przetwarzania transakcyjnego z adresami interfejsu API XA z produktu DB2 Connect. W każdym monitorze przetwarzania transakcyjnego wykonuje się to w inny sposób. Informacje dotyczące udostępniania DB2 XA Switch monitorowi przetwarzania transakcyjnego można znaleźć w podręczniku Administration Guide.
  2. Skonfigurować monitor przetwarzania transakcyjnego z łańcuchem XA_OPEN z DB2. W każdym monitorze przetwarzania transakcyjnego wykonuje się to w inny sposób. Informacje na temat łańcucha XA_OPEN z produktu DB2 Connect można znaleźć w podręczniku Administration Guide. Informacje na temat konfigurowania łańcucha XA OPEN z DB2, w taki sposób, aby mógł być użyty przez monitor przetwarzania transakcyjnego, powinna zawierać dokumentacja dostarczona z konkretnym monitorem przetwarzania transakcyjnego.
  3. W razie potrzeby należy zmodyfikować parametry konfiguracji domyślnej DB2 Connect Sync Point Manager (SPM). Serwery baz danych hosta i systemu AS/400 nie obsługują na razie interfejsu XA.

    SPM jest to komponent produktu DB2 Connect, który odwzorowuje protokół dwufazowego zatwierdzania XA na protokół dwufazowego zatwierdzania, używany przez serwery baz danych hosta i systemu AS/400. Domyślnie instancja DB2 ma predefiniowane wartości parametrów konfiguracyjnych SPM. Parametrem, który ma największe znaczenie jest parametr konfiguracyjny menedżera baz danych SPM_NAME. Domyślnie jest to kombinacja pierwszych siedmiu znaków nazwy hosta TCP/IP.

    Jeśli do połączeń z DB2 for OS/390 używany jest protokół TCP/IP, to nie powinno się zmieniać żadnego z tych domyślnych ustawień. W takim przypadku konfiguracja SPM nie jest wymagana, ponieważ już działa. Jeśli dostęp do serwerów baz danych hosta lub AS/400 następuje za pośrednictwem protokołu SNA, to należy sprawdzić, czy wartość SPM_NAME reprezentuje poprawną jednostkę logiczną SNA w sieci komputerowej. Jeśli wartość domyślna SPM_NAME nie jest akceptowana, należy ją zmodyfikować za pomocą kreatora aktualizacji wielostanowiskowych.


[ Początek strony | Poprzednia strona | Następna strona | Spis treści | Indeks ]