Zarządzanie blokadami

Zarządzanie blokadami ma następujące funkcje w Comarch ERP Enterprise:

• Dostęp do danych — koordynacja dostępu do współdzielonych danych (zasadniczo do Business Objects).
• Wymiana klas — wymiana klas Java w czasie wykonywania.
• Modyfikacja schematu — modyfikacja schematu bazy danych w czasie wykonywania.

W tym artykule znajdują się między innymi informacje jakie typy blokad są używane i jak zaimplementowana jest synchronizacja pamięci podręcznej.

Grupa docelowa

Zarządzanie blokadami jest skierowane do:

• Administratorów systemu
• Programistów

Wymagania wstępne

Wymagana jest następująca wiedza:

• Programowanie
• Architektura Comarch ERP Enterprise

Definicje

• Program ładujący klasy kodu aplikacji — program ładujący klasy kodu aplikacji jest wyspecjalizowanym programem ładującym klasy do ładowania klas logiki aplikacji. Każdy program ładujący klasy kodu aplikacji uzyskuje dostęp do spójnego zestawu klas Java i należy do dokładnie jednej sesji. Programy ładujące klasy kodu aplikacji ładują tylko klasy logiki aplikacji. Różne sesje mogą mieć różne programy ładujące klasy kodu aplikacji. Instancje klas załadowanych za pomocą różnych programów ładujących klasy nie są kompatybilne. Z tego powodu program ładujący klasy kodu aplikacji nie ładuje klas, które są używane w różnych sesjach, takich jak części i obiekty biznesowe lub klasy systemowe.
• Klienci — w komunikacji klient-serwer, klient jest w tym dokumencie utożsamiany z serwerem aplikacji Comarch ERP Enterprise. Serwer jest tutaj serwerem wiadomości.
• Zasoby — zasoby są rozumiane jako:
  • Klasy Java — aplikacje, klasy logiczne, obiekty biznesowe, części
  • Instancje obiektów biznesowych — wszystkie instancje obiektu biznesowego w bazie danych, grupa instancji i pojedyncza instancja specjalna.
• Współdzielona pamięć podręczna — współdzielona pamięć podręczna służy do tymczasowego przechowywania już załadowanych instancji obiektów biznesowych w pamięci głównej w celu uniknięcia dostępu do bazy danych. Jest to zatem ważny komponent, który przyczynia się do wydajności systemu.
  Dostęp do bazy danych w trybie odczytu odbywa się zazwyczaj za pośrednictwem współdzielonej pamięci podręcznej. Po załadowaniu obiektu biznesowego jest on najpierw wyszukiwany w pamięci podręcznej transakcji, następnie we współdzielonej pamięci podręcznej, a na końcu w bazie danych.
• Blokada — w systemie z wieloma użytkownikami konieczne jest regulowanie wykorzystania współdzielonych zasobów. W tym celu wykorzystywana jest blokada. Blokada służy do synchronizacji dostępu do ograniczonych zasobów.
• Podklucz — podklucz jest częścią wieloczęściowego klucza głównego. Wieloczęściowy klucz główny składa się z poziomu zgrubnego i jednego lub więcej poziomów szczegółowych. Podklucz zawsze zaczyna się od poziomu grubszego, a następnie zawiera poziomy drobniejsze.

Żądanie blokady

Blokada jest żądana dla zasobu w określonym kontekście. Konteksty, w których można żądać blokady, są następujące:

• Grupa aktywacji — grupa aktywacji podsumowuje grupę zadań, które używają wspólnego, spójnego zestawu klas Java (porównywalnego do kompilacji/wersji/wydania).
• Zadanie — zadanie odpowiada sesji w Comarch ERP Enterprise.
• Transakcja — termin transakcja jest odpowiednikiem transakcji najwyższego poziomu w Comarch ERP Enterprise.
  Podtransakcje nie są brane pod uwagę w odniesieniu do blokowania. Istnienie blokady jest powiązane z kontekstem, w którym blokada jest wymagana. Różne typy blokad są używane do różnych funkcji. Podział na typy zależy od zasobu, kontekstu i funkcji blokady.

Typy blokad

Dostępne są następujące typy blokad:

• Blokada użycia (Use lock) — blokada użycia ma charakter informacyjny. Ta blokada opisuje, że zasób jest używany przez co najmniej jeden kontekst. Można zażądać więcej niż jednej blokady użycia dla zasobu.
• Blokada wyłączna (Exclusive lock) — blokada wyłączna może być przypisana tylko do jednego kontekstu. Jest ona przypisywana tylko wtedy, gdy żadna blokada użycia nie jest zarejestrowana na tym samym zasobie.

Istnieją blokady odczytu i zapisu w kontekście transakcji.

• Blokada odczytu (Read lock) — blokada odczytu zachowuje się jak blokada użycia. Blokady odczytu na poziomie instancji są wymagane w Comarch ERP Enterprise tylko wtedy, gdy obiekt jest odczytywany z REPEATABLE_READ.
• Blokada zapisu (Write lock) — blokada zapisu zachowuje się jak blokada wyłączna
• Blokady logiczne — blokady logiczne są identyfikowane przez ciąg znaków. Nie blokują one żadnych zasobów, a jedynie mają znaczenie dla aplikacji, która ich używa. Blokady logiczne są zawsze blokadami wyłącznymi i muszą być wyraźnie wymagane. Podobnie jak wszystkie inne blokady, blokady logiczne są również powiązane z istnieniem kontekstu (zadania, transakcji), w którym są wymagane.

Typy blokad

Następujące typy blokad zostały zdefiniowane w celu implementacji funkcjonalności wymaganej do blokowania w Comarch ERP Enterprise:

Typy blokad

ActivationGroupClassUseLock

Program ładujący klasy kodu aplikacji tworzy klasę Java z blokadą tego typu dla każdej aplikacji. Klasy Java dla obiektów biznesowych, części i widoków nie są obsługiwane przez ten typ blokady, ale przez typ blokady JobClassUseLock. Wszystkie zadania uruchomione z tym samym programem ładującym klasy są dostępne w tej samej grupie aktywacji. Program ładujący klasy ładuje spójny zestaw klas Java, które należą do tej samej wersji. Grupa aktywacji jest usuwana, gdy nie jest już przypisana do zadania. Blokady typu ActivationGroupClassUseLock znajdują się w grupie aktywacji i są zwalniane po usunięciu grupy aktywacji.

JobClassUseLock

Użycie klas Java dla obiektów biznesowych, części i widoków w zadaniu jest rejestrowane przez Object Manager i zarządzane za pomocą blokady typu JobClassUseLock. Blokada jest definiowana w kontekście zadania. Jest ona zwalniana po zakończeniu zadania.

JobClassExclusiveLock

Narzędzia systemowe tworzą nowe klasy Java dla obiektów biznesowych, części lub widoków. Aby klasy mogły zostać zastąpione nową wersją, jest ona najpierw blokowana przez inne zadania. W tym celu używany jest typ blokady JobClassExclusiveLock. Ten typ blokady jest zwalniany po zakończeniu zadania. Ten typ blokady może być wymagany tylko wtedy, gdy nie ma innej blokady typu JobClassLock dla danej klasy.

JobObjectUseLock

Jeśli żądana jest blokada transakcji, tj. jeśli jedna lub więcej instancji obiektu biznesowego jest używanych w transakcji, wówczas blokada typu JobObjectUseLock jest ustawiana dla instancji obiektu biznesowego w bazie danych. Blokada tego typu jest zwalniana dopiero po zwolnieniu wszystkich blokad transakcji, które zażądały takiej blokady.

JobObjectExclusiveLock

Blokada typu JobObjectExclusiveLock jest wyraźnie wymagana przez zadanie, które resetuje wszystkie instancje obiektu biznesowego w bazie danych, np. w celu bezpośredniej manipulacji tabelą za pomocą instrukcji bazy danych. Blokada tego typu musi być wyraźnie zwolniona przez zadanie. Można jej zażądać tylko wtedy, gdy nie ma innej blokady typu JobObjectLock dla instancji.

JobLogicalLock

Blokada typu JobLogicalLock jest jawnie wymagana przez zadanie. Można jej zażądać tylko wtedy, gdy nie ma innej blokady typu LogicalLock dla ciągu znaków, który ma zostać zablokowany. Blokada tego typu musi zostać wyraźnie zwolniona.

TransactionKeyReadLock

Blokada typu TransactionKeyReadLock blokuje grupę instancji obiektów biznesowych. Grupa jest identyfikowana przez część klucza wieloczęściowego (podklucz). Blokada odczytu jest ustawiona dla tej grupy, która jest wyraźnie wymagana w ramach transakcji. Jest ona zwalniana po zakończeniu transakcji. Blokady odczytu klucza transakcji są również automatycznie wymagane dla wszystkich krótszych podkluczy dla każdej blokady transakcji.

TransactionKeyWriteLock

Blokada typu TransactionKeyWriteLock blokuje grupę instancji obiektów biznesowych. Grupa jest identyfikowana przez część wieloczęściowego klucza (podklucza). Blokada zapisu jest ustawiona dla tej grupy, która jest wyraźnie wymagana w ramach transakcji. Jest ona zwalniana po zakończeniu transakcji.

TransactionInstanceReadLock

Blokada typu TransactionInstanceReadLock jest wymagana tylko wtedy, gdy obiekt biznesowy jest odczytywany za pomocą polecenia REPEATABLE_READ.

TransactionInstanceWriteLock

Blokada typu TransactionInstanceWriteLock jest wymagana tylko wtedy, gdy obiekt biznesowy jest odczytywany za pomocą polecenia READ_UPDATE lub READ_WRITE.

Zależności

Niektóre z tych typów blokad są współzależne, ponieważ blokują obiekty tego samego typu na różnych poziomach szczegółowości. Tylko typ blokady ActivationGroupClassUseLock jest wyłączony z tego rozważania. Należy zwrócić uwagę na następujące zasady i zależności:

• Blokada na poziomie drobnej szczegółowości jest poprzedzona blokadami na wszystkich poziomach grubszych.
• Typ blokady transakcji jest przekazywany do wszystkich blokad transakcji o większej szczegółowości jako blokada odczytu.
• Dla każdej blokady transakcji, blokady typu TransactionKeyReadLock są wymagane dla wszystkich krótszych podkluczy.
• Blokada użytkowania lub odczytu jest przyznawana, jeśli na tym samym poziomie nie została przyznana blokada wyłączności lub zapisu.
• Blokada wyłączna lub blokada zapisu jest przyznawana tylko wtedy, gdy żadna inna blokada nie została przyznana na tym samym poziomie.

Poniższa tabela kategoryzuje typy blokad zgodnie z ich funkcją w systemie:

Niejawne blokady w Object Manager

W Object Manager blokady typu TransactionInstanceLock są wymagane tylko do odczytu zgodnie z następującymi zasadami:

W przypadku odczytu danych za pomocą klucza głównego należy zażądać blokady bezpośrednio za pomocą tego klucza. W przypadku żądań z kluczem podstawowym najpierw musi zostać obliczony klucz podstawowy. Blokada jest następnie wykonywana przy użyciu klucza podstawowego.

Po przyznaniu blokady obiekt jest odczytywany ponownie, ponieważ obiekt nie był jeszcze zablokowany podczas pierwszego odczytu i mógł zostać zmieniony w międzyczasie. Menedżer blokad zapewnia, że ten drugi odczyt dostarcza aktualnych danych.

Algorytm

Object object = om.getObject (klucz drugorzędny)

AquireLock (object)

object = om.getObject (secondary Key)

Zalety

Zaletą jest szybkość dla interaktywnych aplikacji, które są początkowo odczytywane za pomocą READ i żądają blokady tylko podczas pisania.

Wady

Obiekt jest odczytywany dwukrotnie z bazy danych, jeśli nie jest dostępny we współdzielonej pamięci podręcznej.

Ponieważ inna transakcja może zmienić klucz podstawowy obiektu między pierwszym odczytem a żądaniem blokady, niewłaściwy obiekt jest blokowany i odczytywany. Ponieważ klucze drugorzędne są rzadko lub nigdy nie zmieniane, procedura ta jest nieproblematyczna. W przeciwnym razie procedura ta naturalnie prowadzi do niespójności danych.

W przypadku obiektów zależnych od czasu blokowany jest klucz główny. Powoduje to zablokowanie wszystkich wersji obiektu, ponieważ wszystkie obiekty są zależne od czasu.

Blokady logiczne

Blokady logiczne są używane w Comarch ERP Enterprise na poziomie zadań i aplikacji. W przeciwieństwie do blokad nielogicznych, które blokują zasoby w systemie, blokada logiczna blokuje ciąg znaków, który oznacza semantykę specyficzną dla aplikacji. Jeśli blokada logiczna istnieje dla ciągu znaków w kontekście, to żaden inny kontekst nie otrzymuje blokady dla tego samego ciągu znaków.

Blokady logiczne nie mają wpływu na zachowanie systemu, chyba że są jawnie odpytywane. Blokady logiczne są obserwowane tylko przez aplikacje. Ponadto blokady logiczne nie mają wpływu na żądania blokady typu TransactionInstanceLock.

Blokady aplikacji

Logiczne blokady aplikacji są żądane i zwalniane przez menadżera aplikacji. Blokady aplikacji są automatycznie zwalniane po zamknięciu aplikacji. Żadna inna aplikacja i żadne inne zadanie nie może zablokować tego samego ciągu znaków, jeśli blokada została przyznana dla aplikacji.

Blokady zadań

Logiczne blokady zadań mogą być żądane lub zwalniane przez menadżera systemu. Należy upewnić się, że aplikacja, która zażądała blokady, również wyraźnie zwolniła ją ponownie, w przeciwnym razie blokada pozostanie na miejscu do momentu zakończenia zadania. Inne aplikacje w tym samym zadaniu również otrzymują blokadę zadania, jeśli aplikacja w zadaniu otrzymała już blokadę zadania.

Należy wybrać ciąg znaków tak, aby zawsze jednoznacznie identyfikował zamierzoną semantykę. Jeśli instancja obiektu biznesowego jest powiązana z semantyką, która ma zostać zablokowana, to zazwyczaj wystarczy dołączyć szesnastkową reprezentację atrybutów klucza głównego w ciągu znaków (ze względu na właściwości identyfikatorów GUID).

Ciąg instancji nie zawiera informacji o bazie danych OLTP i klasie obiektu biznesowego. Podczas wybierania ciągu znaków do zablokowania należy wziąć pod uwagę następujące punkty:

• Przypisanie do bazy danych OLTP, jeśli dotyczy
• Typ zablokowanego zasobu
• Identyfikacja zablokowanego zasobu

Serwer klienta

Bazy danych i zawarte w nich obiekty stanowią zasoby w sensie blokady. Jeśli więcej niż jeden serwer aplikacji uzyskuje dostęp do bazy danych, zasoby tej bazy danych są wykorzystywane przez kilka serwerów aplikacji w tym samym czasie. Dostęp do tych zasobów musi być koordynowany pomiędzy serwerami. Do tej koordynacji wykorzystywany jest centralny serwer komunikatów, który centralnie zarządza tabelą blokad. Tabela blokad zawiera wszystkie blokady wszystkich podrzędnych serwerów aplikacji. Każdy serwer aplikacji Comarch ERP Enterprise wysyła zapytanie o swoją blokadę z tej centralnej tabeli blokad. Jeśli tylko jeden serwer aplikacji uzyskuje dostęp do bazy danych w danym czasie, proces synchronizacji, a tym samym komunikacja klient-serwer, nie jest już konieczna.

Komunikacja klient-serwer

Jeśli na bazę danych przypada tylko jeden serwer aplikacji, potrzebny jest tylko jeden lokalny Lock Manager. Żadne inne ścieżki komunikacji lub synchronizacji nie są konieczne dla tego serwera aplikacji lub klienta.

W systemie z kilkoma serwerami aplikacji Comarch ERP Enterprise komunikacja zawsze odbywa się za pośrednictwem serwera wiadomości. Komunikacja między klientami jest nawiązywana za pośrednictwem serwera komunikatów. Jeśli klient wymaga informacji od innych klientów, usługa jest dostępna w serwerze komunikatów.

Serwer komunikatów z klientami

Jeśli kilka serwerów aplikacji (klientów) pracuje z tymi samymi zasobami, tj. z tymi samymi bazami danych i klasami Java, wówczas dostęp do tych zasobów jest koordynowany między serwerami aplikacji. Koordynacja odbywa się za pomocą centralnego serwera komunikatów i blokad. Serwer komunikatów zawiera tabelę blokad, w której zarządzane są wszystkie blokady wszystkich przypisanych serwerów. Każda blokada jest przypisywana z tej centralnej tabeli blokad.

Przyznane blokady są zarządzane lokalnie w każdym serwerze aplikacji Comarch ERP Enterprise. Żądania blokady nie są zatem ponownie przekazywane do centralnej tabeli blokad dla blokad, które zostały już przyznane. Na żądania odpowiada lokalna tabela blokad.

Mechanizm ten usprawnia komunikację klient-serwer dla żądań blokady między serwerem komunikatów a podłączonymi serwerami aplikacji.

Częste żądania blokady od klientów nie wpływają negatywnie na wydajność serwera komunikatów. Z drugiej strony klienci są wolniejsi ze względu na wysiłek związany z komunikacją z serwerem komunikatów.

Następujące typy komunikatów są wymieniane między centralnym serwerem komunikatów a przypisanym serwerem aplikacji Comarch ERP Enterprise.

Wymagania dotyczące blokady

Żądanie blokady zawiera jedną lub więcej blokad. Poszczególne blokady są przesyłane do serwera komunikatów w kolejności, w jakiej zostały zażądane.

Jeśli serwer komunikatów nie może przyznać blokady, kolejne żądane blokady nie są dalej przetwarzane. Blokady już przyznane są wpisywane do lokalnej tabeli blokad serwerów aplikacji. Po przyznaniu blokady serwer komunikatów informuje, czy zablokowany obiekt został w międzyczasie zmieniony. To określa w pamięci podręcznej, czy zablokowany obiekt jest nadal dostępny w bieżącej wersji, czy też musi zostać ponownie odczytany z bazy danych.

Zwalnianie blokady

Jeśli kontekst, taki jak transakcja, zadanie lub grupa aktywacji, zostanie zakończony, wszystkie blokady żądane w tym kontekście zostaną zwolnione w bloku. W centralnym serwerze komunikatów wpisy pamięci podręcznej dla zwolnionych wyłącznych blokad przypisanego serwera aplikacji są usuwane, ponieważ te wpisy pamięci podręcznej mogą być nieprawidłowe. Każda zwolniona blokada jest odnotowywana w serwerze komunikatów do następnej ogólnosystemowej synchronizacji pamięci podręcznej.

Synchronizacja pamięci podręcznej

Ogólnosystemowa synchronizacja pamięci podręcznej jest przeprowadzana w regularnych odstępach czasu (30 sekund). Synchronizacja obejmuje powiadomienie wszystkich serwerów aplikacji (klientów) systemu. Dostarczane są informacje o zmienionych obiektach biznesowych, dla których zwolniono blokady zapisu. Nieprawidłowe obiekty są usuwane z odpowiednich lokalnych współdzielonych pamięci podręcznych.

Stany krytyczne

Podczas żądania i zwalniania blokad występuje stan krytyczny, jeśli serwer komunikatów lub serwer aplikacji (klient) został zakończony. Błędy, które mogą wystąpić, zostały krótko opisane poniżej:

• Serwer aplikacji Comarch ERP Enterprise (klient) — jeśli klient został zakończony, serwer komunikatów zwalnia wszystkie blokady żądane przez klienta.
• Serwer komunikatów — Comarch ERP Enterprise zostaje zakończony na wszystkich klientach, ponieważ nie mogą oni żądać dalszych blokad bez centralnej tabeli blokad.

Synchronizacja współdzielonych pamięci podręcznych

Wynikiem wymiany wiadomości lub synchronizacji między serwerem aplikacji Comarch ERP Enterprise (klientem) a centralnym serwerem wiadomości jest współdzielona pamięć podręczna, która jest zawsze aktualna. Aktualność oznacza, że współdzielona pamięć podręczna jest aktualizowana co 30 sekund. Oznacza to, że tylko aktualne obiekty są przechowywane we współdzielonej pamięci podręcznej. Nieprawidłowe obiekty to te, które zostały (wyłącznie) zablokowane i zwolnione przez inne serwery aplikacji od czasu ostatniej synchronizacji w całym systemie. Jeśli obiekt we współdzielonej pamięci podręcznej nie jest już aktualny, obiekt ten jest ponownie odczytywany z bazy danych przy następnym żądaniu blokady.

Niezależnie od synchronizacji pamięci podręcznej, pamięci podręczne wszystkich serwerów aplikacji nie mogą być spójne bez dużego wysiłku synchronizacyjnego. W tym kontekście spójność oznacza, że powiązane obiekty biznesowe, takie jak jednostka biznesowa, w tym jednostki zależne, są dostępne w tej samej wersji.

Niespójności można zapobiec jedynie poprzez żądanie blokady odczytu dla jednostki biznesowej przy każdym dostępie do odczytu. Z tego powodu aplikacja sama decyduje, kiedy wymagane są spójne dane i za pomocą jakich odpowiednich środków są one odczytywane.

Ustawienie blokad kosztuje stosunkowo dużą ilość mocy obliczeniowej na kliencie i często nie jest konieczne w przypadku dostępu tylko do odczytu. Użytkownicy nie zawsze wymagają absolutnie aktualnych i bieżących danych. Jeśli, na przykład, adres klienta zostanie zmieniony, inne serwery aplikacji nie otrzymają tych nowych informacji natychmiast, ale dopiero po 30 sekundach. Byłoby jednak niedopuszczalne, gdyby nieaktualny rekord danych pozostawał w pamięci podręcznej innych serwerów aplikacji Comarch ERP Enterprise przez godziny lub dni. Z tego powodu serwer komunikatów wysyła wiadomość do serwera aplikacji w regularnych odstępach czasu (co 30 sekund) z kluczami wszystkich obiektów, które zmieniły się w międzyczasie (synchronizacja pamięci podręcznej).

Aby serwer komunikatów mógł poinformować powiązany serwer aplikacji, które obiekty zmieniły się od ostatniej synchronizacji pamięci podręcznej, serwer komunikatów przechowuje listę zmienionych obiektów. Lista ta może stać się bardzo długa w przypadku dużej liczby zmian. W szczególności dane transakcji, które są często zapisywane, prowadzą do dużego zapotrzebowania na pamięć główną i komunikację podczas pracy. Dlatego należy utrzymywać listę zmian tylko dla niektórych obiektów biznesowych.

Lista zmian jest rozszerzana za każdym razem, gdy zwalniana jest blokada transakcji. Lista zmian jest częścią centralnej tabeli blokad w serwerze komunikatów. Jest ona realizowana poprzez dodanie dodatkowych atrybutów Ostatnio zmieniony przez i Nieprawidłowy znacznik dla każdej blokady i każdego serwera aplikacji do tabeli blokad. Nieprawidłowy znacznik jest ustawiany, jeśli serwer aplikacji nie został jeszcze poinformowany o zwolnionej blokadzie. Lista zmian jest usuwana z centralnej tabeli blokad tylko wtedy, gdy informacje o zwolnionych blokadach zostały przesłane do wszystkich serwerów aplikacji, tj. nie jest ustawiony żaden Nieprawidłowy znacznik.

Oprócz listy zmian zarządzana jest lista ostatnio zmienionych obiektów, w której odnotowywane są odniesienia do ostatnio zmienionych obiektów biznesowych zmieniającego się serwera aplikacji. Serwer komunikatów używa żądania blokady i tej listy, aby określić, czy serwer aplikacji (klient) może obecnie przechowywać obiekt w pamięci podręcznej. Oto dwa przykłady:

Jeśli żądanie blokady lub synchronizacja pamięci podręcznej informuje klienta, że obiekt jest nieprawidłowy, klient jest usuwany z listy zmian niezgłoszonych klientów dla obiektu, tj. usuwany jest Nieprawidłowy znacznik. Oznacza to, że każdy klient jest powiadamiany tylko raz na zmianę.