1

1. Model ACID.

2. Deklaratywne zarz dzanie transakcjami,ą● atrybuty transakcji.

3. Propagacja transakcji.

● transakcje rozproszone,

● propagacja kontekstu utrwalania.

3. Izolacja

● typowe problemy,

● blokady,

● poziomy izolacji,

● współbie no ć optymistyczna.ż ś

Transakcje

2

Typowe transakcje s ACID (ą atomic, consistent, isolated, durable):

● atomowe – zbiór operacji wykonanych w cało ci lub wcale,ś● spójne – logika biznesowa zapewnia integralno ć składowanych ś

danych, zmienianych podczas wykonywania transakcji.

● izolowane – brak ingerencji ze strony innych procesów na wykonanie

i przebieg transakcji,

● trwałe – dane nie mog zostać utracone w przypadku awarii ą

systemu.

Transakcje ACID

3

public TicketDO bookPassage(CreditCardDO card, double price)throws IncompleteConversationalState {

if (customer == null || cruise == null || cabin == null) { throw new IncompleteConversationalState( ); } try { Reservation reservation = new Reservation( customer, cruise, cabin, price); entityManager.persist(reservation); this.processPayment.byCredit(customer, card, price); TicketDO ticket = new TicketDO(customer,cruise,cabin,price); return ticket; } catch(Exception e) { throw new EJBException(e); }}

Transakcje ACID

4

Specyfikacja EJB umo liwia deklaratywne zarz dzanie transakcjami.ż ą

Zarz dzanie (niejawne) transakcjami poprzez kontener EJB odbywa si ą ę

na podstawie atrybutów transakcji. S one kontrolowane poprzez ą

adnotacje @TransactionAttribute lub deskryptor wdro enia. Dzi ki ż ę

temu zachowanie transakcji jest niezale ne od logiki biznesowej. ż

Deklaratywne zarz dzanie transakcjami redukuje zło ono ć transakcji ą ż ś

oraz upraszcza tworzenie rozbudowanych aplikacji biznesowych.

Deklaratywne zarz dzanie ątransakcjami

5

Atrybuty transakcji mog być zdefiniowane dla całego komponentu ą

EJB lub dla poszczególnych jego metod. Drugi sposób, choć

trudniejszy, zapewnia wi ksz elastyczno ć. Specyfikacja okre la ę ą ś ś

nast puj ce warto ci dla atrybutów transakcji:ę ą ś● NotSupported,

● Supports,

● Required (domy lnie),ś● RequiresNew,

● Mandatory,

● Never.

Atrybuty transakcji

6

import javax.ejb.Stateless;import javax.ejb.TransactionAttribute;@Stateless

@TransactionAttribute(NOT_SUPPORTED)public class TravelAgentBean implements TravelAgentRemote { public void setCustomer(Customer cust) { ... }

@TransactionAtribute(REQUIRED) public TicketDO bookPassage(CreditCardDO card, double price) { ... } ...}

Atrybuty transakcji

7

<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version=3.0> <assembly-descriptor> <container-transaction> <method> <ejb-name>TravelAgentEJB</ejb-name> <method-name> * </method-name> </method> <trans-attribute>NotSupported</trans-attribute> </container-transaction> <container-transaction> <method> <ejb-name>TravelAgentEJB</ejb-name> <method-name>bookPassage</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor></ejb-jar>

Atrybuty transakcji

8

Wywołanie metody zawiesza transakcj do czasu powrotu. Zakres ę

transakcji nie jest propagowany do komponentu EJB

Atrybut NotSupported

klient EJB EJB

kontekst transakcyjny klientakontekst nietransakcyjny

9

Atrybut Supports powoduje, e zakres transakcji (lub jego brak) jest ż

propagowany do komponentu EJB.

Atrybut Supports

klient EJB EJB

kontekst transakcyjny klientakontekst nietransakcyjny

klient EJB EJB

10

Wywołana metoda zostaje doł czona do kontekstu transakcyjnego ą

klienta. W przypadku jego braku, metoda rozpoczyna własn ą

transakcj w ramach której zostanie wykonana.ę

Atrybut Required

klient EJB EJB

kontekst transakcyjny klientakontekst transakcyjny EJB

klient EJB EJB

kontekst nietransakcyjny

11

Niezale nie od kontekstu klienta, tworzona jest nowa transakcja ż

w ramach której zostanie wykonana wywoływana metoda.

Atrybut RequiresNew

klient EJB

kontekst transakcyjny klientakontekst transakcyjny EJB

klient EJB EJB

kontekst nietransakcyjny

EJB

12

Metoda musi być wykonana w ramach transakcji klienta. Je li ś

wywołanie metody nie nast piło z wn trza transakcji, zostaje ą ę

zwrócony wyj tek.ą

Atrybut Mandatory

klient EJB

kontekst transakcyjny klientakontekst nietransakcyjny

klient EJB EJB

wyj tek ą EJBTransactionRequiredException

EJB

13

Metoda nie mo e być wywołana wewn trz zakresu transakcji.ż ą

Atrybut Never

klient EJB

kontekst transakcyjny klientakontekst nietransakcyjny

klient EJB EJB

wyj tek ą EJBException lub RemoteException

EJB

14

Odwołanie do mened erów encji wymaga istnienia zakresu transakcji. ż

Z tego powodu zaleca si u ywania w tych sytuacjach jednego ę ż

z atrybutów: Required, RequiresNew, Mandatory.

Metody komponentów sterowanych komunikatami mog deklarować ą

jedynie atrybuty Required i NotSupported. Pozostałe atrybuty

odnosz si do transakcji zainicjowanych przez klienta, wiec nie maj ą ę ą

sensu w kontek cie MDB poniewa te komponenty nie s w aden ś ż ą ż

bezpo redni sposób powi zane z klientem.ś ą

Atrybut Mandatory nie mo e być u ywany z metodami stanowi cymi ż ż ą

punkty ko cowe (usługa ń WebServices).

Atrybuty – zalecania i ograniczenia

15

Komponenty bior ce udział w transakcji rejestruj si w menad erze ą ą ę ż

transakcji. Po wykonaniu wszystkich zada przez komponenty, ń

menad er decyduje, czy transakcja zostanie potwierdzona (ż commit),

czy anulowana (rollback). Serwer EJB potrafi współpracować z innymi

systemami transakcyjnymi w celu realizacji tzw. transakcji

rozproszonych. Transakcje rozproszone wymagaj tzw. dwufazowego ą

zatwierdzania. Najpopularniejszym stosowanym tutaj mechanizmem

jest algorytm 2PC.

Propagacja transakcji

16

Protokół 2PC (ang. two-phase commit protocol) rozpoczyna działanie

w momencie rozpocz cia zatwierdzania transakcji rozproszonej ę

i składa si z dwóch etapów. W pierwszym – przygotowanie (ę ang.

prepare), ka dy z uczestników ż transakcji przygotowuje si do jej ę

lokalnego zatwierdzenia. Gdy wszyscy wyrazili gotowo ć ś

zatwierdzenia rozpoczyna si druga faza – zatwierdzenie ę (ang.

commit). Je li jakakolwiek z lokalnych transakcji nie mogła być ś

zatwierdzona, wszystkie s odwoływane. ą

Cały proces dwufazowego zatwierdzania jest koordynowany przez

menad era transakcji.ż

Protokół 2PC

17

Gdy menad er encji o zakresie ograniczonym przez transakcj :ż ę● jest wywoływany poza zakresem transakcji, kontekst utrwalania jest

tworzony na czas wywołania metody,

● jest wywoływany wewn trz transakcji, tworzony jest nowy kontekst ą

pod warunkiem, ze nie istnieje ju kontekst powi zany z t transakcj . ż ą ą ą

W takiej sytuacji zostanie u yty istniej cy kontekst,ż ą● wywołuje stanowy komponent sesyjny z rozszerzonym kontekstem

utrwalania, zgłaszany jest bł d.ą

Propagacja kontekstu utrwalania

18

public List listAvailableCabins(int bedCount) throws IncompleteConversationalState { if (cruise == null) throw new IncompleteConversationalState( ); Query query = entityManager.createQuery("SELECT name " + "FROM Cabin c WHERE c.ship = :ship AND c.bedCount = :beds " + "AND NOT ANY (SELECT cabin from Reservation res " + "WHERE res.cruise = :cruise"); query.setParameter("ship", cruise.getShip( )); query.setParameter("beds", bedCount); query.setParameter("cruise", cruise); return query.getResultList( );}

Izolacja – brudne odczyty

19

...travelAgent.setCabinID(99);

// początek transakcjiagent.bookPassage(card, price){

em.persist(reservation);

pp.byCredit(customer, card, price);}// rollback// koniec transakcji...

Izolacja – brudne odczyty

...// początek transakcjiobj.listAvailableCabins(2);// commit// koniec transakcji:...

2

1

3

4

5

Brudne odczyty (dirty reads) wyst puj gdy jedna transakcja ę ą

odczytuje dane zmieniane przez drug transakcj przed jej ą ę

zatwierdzeniem.

20

...// początek transakcji

agent.listAvailableCabins(2);

agent.listAvailableCabins(2);

// koniec transakcji// commit...

Izolacja – powtarzalne odczyty

...cabin c = em.find(Cabin.class, 99);// początek transakcjic.setBedCount(3);// koniec transakcji:// commit...

21

34

Powtarzalne odczyty (repeatable reads) pojawiaj si je li damy ą ę ś żą

gwarancji, aby wielokrotne odczyty tych samych danych w ramach

transakcji dawały takie same wyniki.

21

...// początek transakcji

agent.listAvailableCabins(2);

agent.listAvailableCabins(2);

// koniec transakcji// commit...

Izolacja – odczyty fantomowe

...agent.setCabin(99);// początek transakcji

agent.bookPassage(card, price){ em.persist(reservation);}// koniec transakcji:// commit...

21

34

Odczyty fantomowe (phantom reads) wyst puj gdy nowy rekord ę ą

dodany do bazy jest rejestrowany przez transakcj , która rozpocz ła ę ę

si przed jego dodaniem.ę

22

Blokady

Aby umo liwić realizacj izolowanych transakcji bazy danych ż ę

wykorzystuj blokady. Podstawowe typy blokad:ą● odczytu – blokuje mo liwo ć zmiany danych odczytanych przez ż ś

transakcj do czasu jej zako czenia. Transakcja nie modyfikuje ę ń

danych (chroni przed powtarzalnymi odczytami),

● zapisu – blokuje mo liwo ć zmiany danych do czasu zako czenia ż ś ń

transakcji, ale umo liwia ich odczyt (brudne odczyty),ż● wył czna do zapisu – blokuje innym transakcjom mo liwo ć zapisu i ą ż ś

odczytu danych do czasu zako czenia transakcji,ń● obrazy (snapshots) – innym transakcjom udost pniana jest kopia ę

danych z momentu przed rozpocz ciem transakcji.ę

23

Poziomy izolacji

Poziom izolacji okre la odporno ć transakcji na oddziaływanie z ś ś

innymi, wykonywanymi równolegle operacjami na bazie danych.

Dost pne poziomy izolacji w technologii JEE s okre lone w ę ą ś

specyfikacji JDBC:

● read uncommited – inne transakcje mog odczytywać ą

niezatwierdzone dane,

● read commited - inne transakcje nie mog odczytywać ą

niezatwierdzonych danych,

● repeatable read - inne transakcje nie mog ani odczytywać ani ą

zmieniać niezatwierdzonych danych poniewa rekordy s blokowane ż ą

podczas operacji odczytu.

● serializable – transakcja ma wył czny dost p do danych, na których ą ę

operuje poniewa nast puje blokada tabel.ż ę

24

Poziomy izolacji

Poziomy izolacji dla zasobów s ustawiane i zarz dzane z poziomu ą ą

kontenera EJB. Dokumentacja kontenera zawiera informacje czy i jak

mo na je modyfikować. Transakcje zarz dzane przez komponenty ż ą

sesyjne lub sterowane komunikatami mog tak e być zarz dzane ą ż ą

poprzez API JDBC:

InitialContext jndi = new InitialContext( ); DataSource source = (javax.sql.DataSource) jndi.lookup( "java:comp/env/jdbc/titanDB"); Connection con = source.getConnection( ); con.setTransactionIsolation( Connection.TRANSACTION_SERIALIZABLE);Nale y pami tać, e stosowanie restrykcyjnych poziomów izolacji ż ę ż

zwykle wpływa niekorzystnie na wydajno ć aplikacji.ś

25

Współbie no ć ż śoptymistyczna

Zało enie:ż transakcje dotycz du ej liczby obiektów ale stosunkowo ą ż

rzadko transakcje odwołuj si do tych samych obiektów.ą ę

Rozwi zanie:ą schemat zarz dzania wersjami.ą

@Entitypublic class CruiseCabin { private int id; private Cabin cabin; private Cruise cruise; private boolean isReserved; private long version; ... @Version protected long getVersion( ) { return version; } ...}

26

Współbie no ć ż śoptymistyczna

public TicketDO bookPassage(CreditCardDO card, double price) throws IncompleteConversationalState { if (customer == null || cruise == null || cabin == null) { throw new IncompleteConversationalState( ); } try { Query query = entityManager.createQuery( "SELECT cc FROM CruiseCabin cc WHERE" + "cc.cabin = :cabin AND cc.cruise = :cruise"); query.setParameter("cabin", cabin); query.setParameter("cruise", cruise); CruiseCabin cc = (CruiseCabin)query.getSingleResult(); if (cc.getIsReserved( )) throw new EJBException("Kabina zarezerwowana"); cc.setIsReserved(true); ... } catch(Exception e) { throw new EJBException(e); }}

UPDATE CRUISE_CABIN SET isReserved=true, version=version + 1 WHERE id = 132 AND version = 101;

27

Zabezpieczenia programowe

Interfejs EntityManager posiada metod ę lock() słu c do żą ą

blokowania danych:

package javax.persistence;public enum LockModeType{ READ, WRITE}

public interface EntityManager { void lock(Object entity, LockModeType type);}

READ eliminuje odczyty brudne i powtarzalne. WRITE dodatkowo

zwi ksza atrybut ę @Version.

28

Podsumowanie

Transakcje s niezb dne aby zapewnić efektywnie i współbie ne ą ę ż

operacje na zgromadzonych danych. Zarz dzanie transakcjami ą

odbywa sie automatycznie (kontener EJB) na podstawie deklaracji.

Jawne zarz dzanie jest mo liwe (JTA) ale niezalecane.ą ż

Spójno ć przetwarzanych danych mo e być zapewniona poprzez ś ż

wła ciwy dobór poziomów izolacji oraz blokad.ś