Wzorce dystrybucji i wspolbieznosci autonomicznej.
Transkrypt
Wzorce dystrybucji i wspolbieznosci autonomicznej.
Wzorce dystrybucji i wspólbieżności autonomicznej 1. Wzorce dystrybucji, ● fasada zdalna (Remote Facade), ● obiekt transfery danych (Data Transfer Object), 2. Wzorce współbieżności autonomicznej, ● blokada optymistyczna (Optimistic Offline Lock), ● blokada pesymistyczna (Pessimistic Offline Lock), ● blokada gruboziarnista (Coarse-Grained Lock), ● blokada domyślna (Implicit Lock). 1 Remote Facade fasada klienta klient getClientData() getName() getAddress() getBirthDate() Fasada ma na celu ograniczyć liczbę zdalnych wywołań poprzez grupowanie żądań i odpowiedzi. 2 Remote Facade Podstawowe cechy fasady zdalnej: ● umożliwia wyłącznie komunikację pomiędzy interfejsem szczegółowym (lokalnym) a ogólnym (zdalnym). ● nie zawiera logiki – jedynie przesyła dane, ● udostępniane operacje zwykle odpowiadają konkretnym działaniom aplikacji klienckiej, Inne często wykorzystywane funkcje: ● mechanizm zabezpieczeń poprzez listy użytkowników mogących wywoływać metody fasady, ● naturalna kontrola zakresu transakcji. 3 Remote Facade Podobne wzorce: ● Session Facade – obudowuje dostęp do komponentów encyjnych. Zwykle jest to implementacja wzorca Transaction Script czyli zawiera logikę dziedziny. ● Service Layer – podstawowa różnica: warstwy usług nie musi być zdalna oraz może zawierać logikę aplikacji. W niektórych wypadkach fasada zdalna może być częścią warstwy usług lub umożliwiać dostęp do niej. 4 Data Transfer Object Order OrderDTO value ... value address ... serialize deserialize * OrderAssembler 1 Customer address ... Data Transfer Object przenosi dane pomiędzy procesami, pozwalając na zmniejszenie liczby zdalnych wywołań. 5 Data Transfer Object Ze względu na długi czas realizacji zdalnych operacji bardziej opłacalne jest przesłanie zbyt wielu danych niż wielokrotne wywoływanie zdalnych metod. Często spotykaną formą DTO jest wzorzec Record Set. Obiekty DTO zwykle tworzy się ze względu na potrzeby klienta – np. jeden obiekt zawiera wszystkie informacje potrzebne do wyświetlenia strony www. Dane są przesyłane w formie zserializowanej (zwykle binarnej lub XML). Obiekty DTO powinny być całkowicie niezależne od obiektów dziedziny (i odwrotnie). Dlatego do aplikacji dołącza się odpowiednie obiekty potrafiące tworzyć obiekty DTO na podstawie obiektów dziedziny i odwrotnie. 6 Przetwarzanie współbieżne Współbieżność rodzi szereg charakterystycznych problemów związanych z możliwymi interakcjami pomiędzy działającymi procesami. Typowe problemy pojawiające się w aplikacjach biznesowych to: ● utracone aktualizacje – wprowadzone zmiany nie są widoczne dla wszystkich procesów i w związku z tym mogą zostać niezapisane, ● niespójne odczyty – odczytywane w różnych momentach części danych są niespójne ze względu na wprowadzone w międzyczasie zmiany. Problemy rozwiązuje się wprowadzając blokady. 7 Optimistic Offline Lock Blokada optymistyczna zakłada niskie ryzyko wystąpienia konfliktu i w związku z tym dopuszcza wielu użytkowników do operowania na wspólnych danych. W przypadku, gdy jeden z procesów chce dokonać aktualizacji danych należy sprawdzić czy w międzyczasie inny proces ich nie zmodyfikował. W takim przypadku wprowadzone zmiany są wycofywane. Najczęstszy sposób implementacji: numery wersji. 8 Optimistic Offline Lock proces baza danych SELECT Document edycja dokumentu UPDATE Document SET ..., version = v+1, WHERE id = ? AND version = v ilość zaktualizowanych wierszy if (ilość!=1) failed(); 9 Optimistic Offline Lock Alternatywna implementacja: warunki dla każdego pola w dokumencie. Zalety: ● nie trzeba dodawać pola wersji do tabeli, Wady: ● skomplikowana postać instrukcji UPDATE (DELETE), ● negatywny wpływ na wydajność. Należy zwrócić uwagę, że obie implementacje nie chronią przed niespójnymi odczytami. 10 Pessimistic Offline Lock Blokada pesymistyczna zapobiega konfliktom poprzez całkowite ich wyeliminowanie. Transakcja biznesowa musi uzyskać blokadę umożliwiającą modyfikowanie danych zanim zacznie ich używać. Blokada pesymistyczna jest implementowana w trzech fazach: ● określenie rodzaju blokady, ● stworzenie menedżera blokad, ● zdefiniowanie procedur używanych w celu uzyskania blokady. 11 Pessimistic Offline Lock CREATE TABLE lock(lid bigint primary key, owner varchar(64) ) public class ExclusiveReadLockManagerImpl implements ExclusiveReadLockManager{ public void getLock(long lock, String sOwner){ if(!this.hasLock(lock, sOwner)){ try{ Connection con = ConnectionManager.getInstance(). getConnection(); PreparedStatement pstmt = con.prepareStatement( "INSERT INTO lock VALUES(?, ?)"); pstmt.setLong(1, lock); pstmt.setString(2, sOwner); pstmt.executeUpdate(); }catch(SQLException ex){ throw new LockException( "Nie mozna uzyskac blokady..."); }finally{ this.closeDB(); } } } 12 Pessimistic Offline Lock } private void releaseLock(long lock, String sOwner){ try{ Connection con = ConnectionManager.getInstance(). getConnection(); PreparedStatement pstmt = con.prepareStatement( "DELETE FROM lock WHERE lid = ? AND owner = ?"); pstmt.setLong(1, lock); pstmt.setString(2, sOwner); pstmt.executeUpdate(); }catch(SQLException ex){ throw new LockException("..."); }finally{ this.closeDB(); } } ... 13 Pessimistic Offline Lock Przykład zastosowania (aktualizacja danych klienta przez www): ● właścicielem blokady jest sesja klienta – przy jej tworzeniu usuwane są wszystkie założone przez nią blokady. ● metoda getLock() jest wywoływana przed każdą operacją dotyczącą obiektu reprezentującego klienta. Argumenty metody to identyfikator klienta oraz identyfikator sesji. ● obiekt klienta jest utrwalany w bazie danych po czym blokada jest usuwana releaseLock(). ● na końcu sesji usuwane są wszystkie jej blokady. 14 Coarse-Grained Lock Blokada gruboziarnista blokuje grupę powiązanych ze sobą obiektów za pomocą pojedynczej blokady. Często, w przypadku zmiany powiązanych ze sobą obiektów stosowanie blokady optymistycznej pojedynczych obiektów jest nieefektywne (duża liczba odwołań do bazy), natomiast blokada pesymistyczna dotycząca poszczególnych obiektów jest trudna do realizacji i powodować rywalizację procesów na poziomie dostępu do tablicy blokad. Typowym problemem jest też wyszukanie obiektów, które powinny być zablokowane (np. w momencie zakładania blokady mogą one nie istnieć). 15 Coarse-Grained Lock Implementacja polega na stworzeniu obiektu wykorzystywanego do blokowania całej grupy. Przykład – obiekt wersji dla blokady optymistycznej. Order * value ... Version * getValue() increment() 1 Customer address ... 1 * 1 16 Coarse-Grained Lock public class Version { public static Version find(long id){ Version v = session.getIdentityMap.getVersion(id); if (v==null) v = Version.load(id); return v; } private static Version load(long id) { ... "SELECT id, value, modifiedBy, date FROM version WHERE id = ?"; ... } public static Version create(){ Version v = new Version(IdGenerator.nextId(), 0, session.getUser(), new Date()); v.isNew = true; return v; } 17 Coarse-Grained Lock } public void insert(){ if (this.isNew){ ... "INSERT INTO version VALUES(?, ?, ?, ?)"; ... this.isNew = false; } } public void increment(){ if (!this.isLocked){ ... "UPDATE version SET value = value+1, ... WHERE id = ?"; ... this.value++; locked = true; if (updatedRowCount==0) throw new ConcurencyException("..."); } } 18 Coarse-Grained Lock W przypadku blokady pesymistycznej wspólny obiekt pełni rolę żetonu określającego, czy dana grupa może zostać zablokowana. Order * value ... Version * getValue() increment() 1 Customer address ... 1 * 1 1 Pessimistic Lock 1 19 Implicit Lock Mechanizm blokowania działa dopóki jest spójnie i konsekwentnie stosowany. Brak pobrania blokady choćby w jednym miejscu kodu może sprawić, że cały schemat blokowania staje się bezużyteczny. Jednym z pomysłów rozwiązania tego problemu jest stosowanie blokad domyślnych, które nie muszą (nie powinny) być wywoływane jawnie przez programistę. 20 Implicit Lock transakcja biznesowa szkielet menedżer blokad wczytaj obiekt zablokuj obiekt powodzenie zwróć obiekt W przypadku blokad optymistycznych mechanizm blokady domyślnej zaleca się stosować zawsze. Dla blokad pesymistycznych należy uważać na możliwe zaglożenia – np. zakleszczenia. 21 Podsumowanie W aplikacjach biznesowych stosuje się mechanizmy mające na celu zwiększenie wydajności systemu. Podstawowe techniki to optymalizacja zdalnych wywołań oraz współbieżność. W tym drugim przypadku należy mieć na uwadze problemy związane z jednoczesnym dostępem kilku procesów do tych samych danych. Aby zlikwidować potencjalne trudności stosuje się blokady, które w miarę możliwości nie ograniczają poziomu współbieżności. 22