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

Podobne dokumenty