1 / 25

Transaktioiden ongelmat web-sovelluksissa

Transaktioiden ongelmat web-sovelluksissa. Verkkotekniikan jatkokurssi kevät 2003 V. Seppänen (rissepp@cc.jyu.fi). read, write. begin transaction. commit. prepare. active. committed. abort. failed. terminated. Transaktiot?, 1. Tapahtuma, joka on Jakamaton (atomic)

kaili
Télécharger la présentation

Transaktioiden ongelmat web-sovelluksissa

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Transaktioiden ongelmat web-sovelluksissa Verkkotekniikan jatkokurssi kevät 2003 V. Seppänen (rissepp@cc.jyu.fi)

  2. read, write begintransaction commit prepare active committed abort failed terminated Transaktiot?, 1 • Tapahtuma, joka on • Jakamaton (atomic) • Erityvä (isolated) • Johdonmukainen (consistent) • Pysyvä (durable)  ACID-ominaisuudet • Transaktioiden juuret tietokantasovelluksissa

  3. Transaktiot?, 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

  4. 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..?

  5. Eriytyvyys, 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 Control Olettaa, että transaktiot pyrkivät harvoin päivittämään samanaikaisesti samoja kohteita.

  6. Eriytyvyys, 2 OCC, jatkuu… • vaihe: T1 lukee tarvittavat tietokohteet ja suorittaa mahd. muutokset kopioon • 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. • T1:n muutokset kirjoitetaan vars. dataan. Two-Phase Locking (2-vaiheinen lukitus) Jokainen luku- ja kirjoitusoperaatio suojataan lukitsemalla tarvittavat tietokohteet

  7. Eriytyvyys, 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.

  8. Eriytyvyys, 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?

  9. 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?

  10. Eriytyvyys, 6Case 2: Tietokantapohjainen sovellus • TKHJ:n tarjoamat mahdollisuudet trans. hallintaan • Sleep simuloikoon samanaikaisuutta • Arvioita?

  11. Jakamattomuus, 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.

  12. 4. 3. 2. 1. Tietokantapalvelin Salasanapalvelin WWW-palvelin Asiakas Jakamattomuus, 2

  13. Jakamattomuus, 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…

  14. Abort Commit Commit? Commit? OK OK Commit? Commit? Commit Abort OK OK Commit? Commit? OK NOT OK Abort Commit Jakamattomuus, 4 • Two-phase commit: • Esimerkki nk. Atomic commitment protokollasta • Soveltuu hajautettuihin järjestelmiin, joilta vaaditaan transaktionaalista toimintaa

  15. Pari ‘kehittyneempää’ transaktiomallia

  16. Long-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

  17. 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

  18. t0 t1 t2 t3 t4 Nested 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

  19. 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

  20. 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

  21. Saga 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

  22. 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

  23. Sagas & 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

  24. C F G A B D E H I Backward recovery - compensation Failure Save-point Forward recovery Execution graph 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

  25. Yhteenveto • 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ä!

More Related