transaktioiden ongelmat web-sovelluksissa

25
Transaktioiden ongelmat web- sovelluksissa Verkkotekniikan jatkokurssi kevät 2003 V. Seppänen ([email protected])

Upload: kaili

Post on 17-Jan-2016

26 views

Category:

Documents


0 download

DESCRIPTION

Transaktioiden ongelmat web-sovelluksissa. Verkkotekniikan jatkokurssi kevät 2003 V. Seppänen ([email protected]). read, write. begin transaction. commit. prepare. active. committed. abort. failed. terminated. Transaktiot?, 1. Tapahtuma, joka on Jakamaton (atomic) - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Transaktioiden ongelmat web-sovelluksissa

Transaktioiden ongelmat web-sovelluksissa

Transaktioiden ongelmat web-sovelluksissa

Verkkotekniikan jatkokurssi

kevät 2003V. Seppänen ([email protected])

Page 2: Transaktioiden ongelmat web-sovelluksissa

Transaktiot?, 1Transaktiot?, 1

• Tapahtuma, joka on Jakamaton (atomic) Erityvä (isolated) Johdonmukainen

(consistent) Pysyvä (durable)

ACID-ominaisuudet

prepare active committed

failed terminated

begintransaction

read, write

commit

abort

• Transaktioiden juuret tietokantasovelluksissa

Page 3: Transaktioiden ongelmat web-sovelluksissa

Transaktiot?, 2Transaktiot?, 2

• Simple failure semantics: if anything goes wrong restart

• Log/state based recovery returns the original data: work is lost and must be redone

• Concurrency conflicts on long-running actions; possible deadlocks

• Collaboration amongst transactions not supported

Page 4: Transaktioiden ongelmat web-sovelluksissa

ACID-ominaisuuksien vaaliminen

ACID-ominaisuuksien vaaliminen

• ‘Vähemmän’ ongelmalliset C ja D• Johdonmukaisuus: hoitettavissa yleensä

järkevällä ohjelmoinnilla tai tietokantaan määritellyillä eheyssäännöillä määritellään datalle ja järjestelmälle sallitut tilat, ei sallita laittomia operaatioita (kts. kalvo Eriytyvyys, 6)

• Pysyvyys: varmistetaan tiedon säilyvyys virhetilanteissa, ‘katastrofeissa’, jne. Pidetään tieto turvassa ja palautettavissa

• Entä eriytyvyys ja jakamattomuus..?

Page 5: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 1Eriytyvyys, 1

• Sarjallistuva ajoitus = lopputulos vastaa jotain sarjallista suoritusta.

• Hallintakeinoja mm. Timestamping (aikaleimaus)

Transaktiolle (T) annetaan aloitushetkellä aikaleima ajanmukaan kasvavasta järjestetystä alueesta.

Operaatio pi[x] suoritetaan ennen operaatiota qj[x] mikäli Ti:n aikaleima on pienempi kuin Tj:n.

Optimistic Concurreny ControlOlettaa, että transaktiot pyrkivät harvoin päivittämään

samanaikaisesti samoja kohteita.

Page 6: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 2Eriytyvyys, 2

OCC, jatkuu…

1. vaihe: T1 lukee tarvittavat tietokohteet ja suorittaa mahd. muutokset kopioon

2. vaihe: tutkitaan, onko muut T:t käyttäneet tällä välin samaa tietoa. Mikäli on, peruutetaan T1, muutoin siirrytään seuraavaan vaiheeseen.

3. T1:n muutokset kirjoitetaan vars. dataan.

Two-Phase Locking (2-vaiheinen lukitus)

Jokainen luku- ja kirjoitusoperaatio suojataan lukitsemalla tarvittavat tietokohteet

Page 7: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 3Eriytyvyys, 3

2-PL jatkuu…Lukulukko on jaettu, ts. muut T:t voivat saada

samaan kohteeseen lukulukon saman aikaisesti. Kirjoituslukittua kohdetta eivät muut T:t voi kirjoitus- tai lukulukita

Vapautettuaan lukon, T ei voi saada enää uusia lukkoja Laajenemisvaihe: T kerää tarvitsemansa lukot; Supistumisvaihe: T vapauttaa varaamiaan lukkoja

2-PL:sta useita versioita, esim. konservatiivinen ja tiukka. Eri versioiden välillä lukkojen-vapautustekniikka vaihtelee.

Page 8: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 4Eriytyvyys, 4

• Sopivan menetelmän valinta sovelluksen tyypin ja toiminta-alustan perusteella Käytetäänkö tietokantaa vai esim. flat-

tiedostoja? Minkätyyppistä tietoa käsitellään? Onko samanaikaisia käyttäjiä tavallisesti

useita? Suositaanko mieluummin peruutusta vai

odotusta?

Page 9: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 5Case 1: Julkaisujärjestelmät

Eriytyvyys, 5Case 1: Julkaisujärjestelmät

• Dokumenttien luonti ja päivittäminen web-käyttöliittymän kautta.

• Demo 1

• Demo 2

• Demo1: Ei samanaikaisuuden hallintaa

• Demo2: Optimistinen samanaikaisuuden hallinta

• Arvioita?

Page 10: Transaktioiden ongelmat web-sovelluksissa

Eriytyvyys, 6Case 2: Tietokantapohjainen sovellus

Eriytyvyys, 6Case 2: Tietokantapohjainen sovellus

• TKHJ:n tarjoamat mahdollisuudet trans. hallintaan• Sleep simuloikoon samanaikaisuutta

• Arvioita?

Page 11: Transaktioiden ongelmat web-sovelluksissa

Jakamattomuus, 1Jakamattomuus, 1

• a) Suoritetaan onnistuneesti kaikki transaktioon kuuluvat operaatiot TAI b) ei tehdä mitään (vrt. ed. kalvo) Mikäli a) transaktion tekemät muutokset vahvistetaan

(commit) Mikäli b) muutoksia tehneiden operaatioiden

vaikutukset peruutetaan (rollback)

• Sovelletaan myös muualla kuin tietokantatransaktioissa; prosessien hallinta, liiketoimintaan liittyvät sovellukset jne.

Page 12: Transaktioiden ongelmat web-sovelluksissa

Jakamattomuus, 2Jakamattomuus, 2

Salasanapalvelin Tietokantapalvelin

WWW-palvelin

Asiakas

3.2.

4.

1.

Page 13: Transaktioiden ongelmat web-sovelluksissa

Jakamattomuus, 3Jakamattomuus, 3

• Edelliseen:• Siirtyminen vaiheesta toiseen, vain jos edellinen vaihe

suoritettu OK• Ongelmana HTTP:n tilattomuus: miten

valvotaan/ylläpidetään tietoa siitä, että tarvittavat vaiheet on suoritettu?

• Miten taata tiedon siirtyminen solmusta toiseen?• Kuinka toimia ongelmatilanteissa?• Toteutus vaatii kokonaisvaltaista suunnittelua…

Page 14: Transaktioiden ongelmat web-sovelluksissa

Jakamattomuus, 4Jakamattomuus, 4

• Two-phase commit: Esimerkki nk. Atomic commitment protokollasta Soveltuu hajautettuihin järjestelmiin, joilta vaaditaan

transaktionaalista toimintaaCommit?

Commit?

Commit?OK

OK

OK

Commit

Commit

Commit

Commit?

Commit?

Commit?NOT OK

OK

OK

Abort

Abort

Abort

Page 15: Transaktioiden ongelmat web-sovelluksissa

Pari ‘kehittyneempää’ transaktiomallia

Pari ‘kehittyneempää’ transaktiomallia

Page 16: Transaktioiden ongelmat web-sovelluksissa

Long-living transactionsLong-living transactions

• Run for a long period of time: may consist of various nested short activities or fewer long activies

• Often distributed: communication through a reliable messaging environment

• Usually keep resources locked for the long periods, which may significantly delay the commit of other simultaneous transactions

Page 17: Transaktioiden ongelmat web-sovelluksissa

Long-living trans., cont.Long-living trans., cont.

• Typically large in sense that they access a number of separate data objects. The deadlock frequency grows with the fourth power of the transaction’s size.

• Often require relaxed transactional semantics in terms of atomicity and isolation Visibility of intermediate results Non-serializable not possible to use state based

rollback

Page 18: Transaktioiden ongelmat web-sovelluksissa

Nested transactionsNested transactions

• A large transaction decomposed to a tree of subtransactions A parent can have any number of children Any number of children may be active concurrently Each trans. can commit or abort Children are serializable with respect to their siblings (must obey

read-write and write-write rules) Lock inheritanced from parents to children, and given back after

child commits (anti-inheritance)

• Commit of child relative to its parent The commit of trans will only become effective if its predecessor

trans commits; updates persist only if all predecessors commit

t0

t2

t3 t4

t1

Page 19: Transaktioiden ongelmat web-sovelluksissa

Nested trans., cont.Nested trans., cont.

If a transaction aborts, all the other transactions in its subtree are aborted too; also updates of committed children are undone

Modifications on resources of a trans become visible to its parents if the trans commits

Modifications on resources of a trans are only visible to itself and its children

• Parent can commit only after all its children have terminated• The main advantages of nested trans.

The support of modularity: decomposition of transactions composition of separately developed modules

Page 20: Transaktioiden ongelmat web-sovelluksissa

Nested trans., cont.Nested trans., cont.

• Advantages… Failure handling at the granularity of

subtransactions: finer control of error; improved availability

Intra-transactional parallelism: subtransactions can be executed concurrently; reduced response time

Page 21: Transaktioiden ongelmat web-sovelluksissa

Saga transactionsSaga transactions

• A long-living transaction, broken up into a collection of subtransaction that can be interleaved with other transactions

T1, T2, …, Tn

• Subtransactions execute and commit independently but must finally form an atomic unit

• After Ti finishes, it releases its locks and exposes results to any other transaction

Page 22: Transaktioiden ongelmat web-sovelluksissa

Sagas, cont.Sagas, cont.

• For each Ti there is a compensating transaction Ci

• Compensating transactions defined on-the-fly if possible

• The purpose of Ci is to logically / semantically undo Ti’s updates

• If compensation is not needed saga executes as a series of ACID transactions: T1, T2, …, Tn

• If compensation is needed, the execution sequence would be: T1, T2, …, Tj, Cj, …, C2, C1

Page 23: Transaktioiden ongelmat web-sovelluksissa

Sagas & Save-pointsSagas & Save-points

• Can be seen as a check point in a transaction (in saga, open nested trans, etc.), which forces the system to save the state of the running application and returns a save-point identifier for future reference

• In a failure, instead of compensating all subtransactions, system needs to compensate only the transactions that were executed subsequently to the last found save-point

Page 24: Transaktioiden ongelmat web-sovelluksissa

Sagas & Save-points, cont.Sagas & Save-points, cont.

• Backward recovery: using compensating operations

• Forward recovery: after the backward recovery a saga continues by executing remaining transactions: the one that caused a failure and the following ones

A B D E H I

GFC

FailureSave-point

Execution graph

Backward recovery - compensationForward recovery

Page 25: Transaktioiden ongelmat web-sovelluksissa

YhteenvetoYhteenveto

• Web ei missään nimessä ole otollinen alusta transaktionaalisia ominaisuuksia vaativille sovelluksille: Hajautettu ympäristö; HTTP ei itsessään tue trans.

toimintaa: yksink. pyyntö/vastaus-malli ilman QoS-takuuta

Latenssi Tilattomuus Yhteydettömyys

• Paljon huomioitavaa, paljon mietittävää, vaatii kompromisseja.

• Hyvää pääsiäistä!