Liiketoimi
Tapahtuma on datan toimintosarja, jolla on alku ja loppu.
Tapahtuma on luku- ja kirjoitustoimintojen peräkkäinen suoritus. Tapahtuman lopetus voi olla joko muutosten tallentaminen (commit) tai muutosten peruuttaminen (palautus). Suhteessa tietokantaan tapahtuma koostuu useista pyynnöistä, joita käsitellään yhtenä pyyntönä.
Tapahtumien on täytettävä ACID-ominaisuudet
Atomuus. Kauppa toteutuu joko kokonaan tai ei ollenkaan.
Johdonmukaisuus. Tapahtumaa suoritettaessa tiedoille asetettuja rajoituksia (esimerkiksi tietokannan rajoituksia) ei saa rikkoa. Johdonmukaisuus tarkoittaa, että järjestelmä siirtyy oikeasta tilasta toiseen oikeaan tilaan.
Eristäytyminen. Rinnakkaiset tapahtumat eivät saa vaikuttaa toisiinsa, esimerkiksi muuttaa toisen tapahtuman käyttämiä tietoja. Rinnakkaisten tapahtumien suorittamisen tuloksen tulisi olla sama kuin jos tapahtumat suoritettaisiin peräkkäin.
Kestävyys. Kun olet sitoutunut, muutoksia ei pidä menettää.
Tapahtumaloki
Loki tallentaa tapahtumien tekemät muutokset, varmistaa tietojen atomiteetin ja vakauden järjestelmävian sattuessa
Loki sisältää arvot, jotka tiedoilla oli ennen ja jälkeen tapahtuman muuttamisen. Eteenpäin kirjoittava lokistrategia edellyttää lokimerkinnän lisäämistä aiemmista arvoista ennen aloitusta ja lopullisista arvoista tapahtuman päätyttyä. Järjestelmän äkillisen pysähdyksen sattuessa tietokanta lukee lokin käänteisessä järjestyksessä ja peruuttaa tapahtumien tekemät muutokset. Keskeytyneen tapahtuman havaittuaan tietokanta suorittaa sen ja tekee siihen muutoksia lokiin. Kun tietokanta on vikatilanteen tilassa, se lukee lokin eteenpäin järjestyksessä ja palauttaa tapahtumien tekemät muutokset. Näin jo tehtyjen tapahtumien vakaus ja keskeytyneen tapahtuman atomiteetti säilyvät.
Pelkkä epäonnistuneiden tapahtumien uudelleen suorittaminen ei riitä palautukseen.
Esimerkki. Käyttäjällä on tilillään 500 dollaria ja käyttäjä päättää nostaa sen pankkiautomaatista. Kaksi kauppaa on meneillään. Ensimmäinen lukee saldon arvon ja jos saldolla on riittävästi varoja, se antaa rahaa käyttäjälle. Toinen vähentää vaaditun summan saldosta. Oletetaan, että järjestelmä kaatui ja ensimmäinen toiminto epäonnistui, mutta toinen epäonnistui. Tässä tapauksessa emme voi antaa uudelleen rahaa käyttäjälle palauttamatta järjestelmää alkuperäiseen tilaan positiivisella saldolla.
Eristystasot
Lue Sitoutunut
Dirty Read -ongelma on, että tapahtuma voi lukea toisen tapahtuman välituloksen.
Esimerkki. Alkusaldon arvo on 0 dollaria. T1 lisää 50 dollaria saldoosi. T2 lukee saldon arvon (50 dollaria). T1 hylkää muutokset ja poistuu. T2 jatkaa suoritusta virheellisillä saldotiedoilla.
Ratkaisu on lukea kiinteää dataa (Read Committed), joka estää tapahtuman muuttamien tietojen lukemisen. Jos tapahtuma A on muuttanut tiettyä tietojoukkoa, tapahtuma B joutuu näihin tietoihin pääsyn yhteydessä odottamaan tapahtuman A valmistumista.
Toistettava luku
Kadonneiden päivitysten ongelma. T1 tallentaa muutokset T2:n muutosten päälle.
Esimerkki. Alkusaldon arvo on 0 dollaria ja kaksi tapahtumaa täydentävät saldoa samanaikaisesti. T1 ja T2 lukevat 0 dollarin saldon. T2 lisää sitten $200 $0:aan ja tallentaa tuloksen. T1 lisää $100 $0:aan ja tallentaa tuloksen. Lopputulos on 100 dollaria 300 dollarin sijaan.
Toistamaton lukuongelma. Saman tiedon lukeminen toistuvasti palauttaa eri arvot.
Esimerkki. T1 lukee saldon arvon $0. T2 lisää sitten 50 dollaria saldoon ja loppuu. T1 lukee tiedot uudelleen ja löytää poikkeaman edellisen tuloksen kanssa.
Toistuva luku varmistaa, että toinen luku palauttaa saman tuloksen. Yhden tapahtuman lukemia tietoja ei voida muuttaa muissa ennen kuin tapahtuma on suoritettu. Jos tapahtuma A on lukenut tietyn datajoukon, tapahtuma B joutuu näihin tietoihin pääsyn yhteydessä odottamaan tapahtuman A valmistumista.
Tilattu lukema (sarjoitettava)
Phantom Reads -ongelma. Kaksi kyselyä, jotka valitsevat tietoja tietyn ehdon perusteella, palauttavat eri arvot.
Esimerkki. T1 pyytää kaikkien käyttäjien lukumäärää, joiden saldo on suurempi kuin 0 dollaria mutta alle 100 dollaria. T2 vähentää 1 dollarin käyttäjältä, jonka saldo on 101 dollaria. T1 lähettää pyynnön uudelleen.
Tilattu lukema (sarjoitettava). Tapahtumat suoritetaan täysin peräkkäin. Pyynnön ehtojen mukaisten tietueiden päivittäminen tai lisääminen on kiellettyä. Jos tapahtuma A on pyytänyt tietoja koko taulukosta, koko taulukko jäädytetään muille tapahtumille, kunnes tapahtuma A on valmis.
Aikataulu
Asettaa järjestyksen, jossa toiminnot tulee suorittaa rinnakkaisten tapahtumien aikana.
Tarjoaa tietyn eristystason. Jos operaatioiden tulos ei riipu niiden järjestyksestä, niin operaatiot ovat kommutatiivisia (Permutable). Lukuoperaatiot ja operaatiot eri datalle ovat kommutatiivisia. Luku-kirjoitus- ja kirjoitus-kirjoitustoiminnot eivät ole kommutatiivisia. Aikatauluttajan tehtävänä on lomittaa rinnakkaisten tapahtumien suorittamat toiminnot siten, että suorituksen tulos vastaa tapahtumien peräkkäistä suorittamista.
Mekanismit rinnakkaisten töiden hallintaan (Concurrency Control)
Optimistisuus perustuu konfliktien havaitsemiseen ja ratkaisemiseen, pessimistisyys konfliktien syntymisen estämiseen.
Optimistisessa lähestymistavassa useilla käyttäjillä on käytettävissään kopiot tiedoista. Ensimmäinen muokkauksen suorittanut henkilö tallentaa muutokset, kun taas muiden on yhdistettävä muutokset. Optimistinen algoritmi sallii konfliktin esiintymisen, mutta järjestelmän on toiputtava konfliktista.
Pessimistisellä lähestymistavalla ensimmäinen käyttäjä, joka kaappaa tiedot, estää muita vastaanottamasta tietoja. Jos konfliktit ovat harvinaisia, on viisasta valita optimistinen strategia, koska se tarjoaa korkeamman tason samanaikaisuutta.
Lukitus
Jos yhdessä tapahtumassa on lukittuja tietoja, muiden tapahtumien on odotettava, kunnes se avataan, kun tietoja käsitellään.
Lohko voidaan peittää tietokannan, taulukon, rivin tai attribuutin päällä. Jaettu lukitus voidaan asettaa samalle tiedolle useilla tapahtumilla, se sallii kaikkien tapahtumien (mukaan lukien se, joka asetti sen) lukea, estää muuttamisen ja yksinomaisen kaappauksen. Exclusive Lock voidaan asettaa vain yhdellä tapahtumalla, se sallii kaikki määräävän tapahtuman toimet, estää muiden toimet.
Umpikuja on tilanne, jossa tapahtumat päätyvät odottavaan tilaan, joka kestää loputtomasti.
Esimerkki. Ensimmäinen tapahtuma odottaa, että toisen kaappaama data vapautetaan, kun taas toinen odottaa, että ensimmäisen kaappaama data vapautetaan.
Optimistinen ratkaisu lukkiutumisongelmaan sallii lukkiutumisen tapahtumisen, mutta palauttaa sitten järjestelmän palauttamalla yhden lukkiutumiseen liittyvistä tapahtumista.
Umpikujaa etsitään tietyin väliajoin. Yksi havaitsemismenetelmistä on aika, eli katsoa lukkiutumisen tapahtuneen, jos tapahtuman suorittaminen kestää liian kauan. Kun umpikuja löytyy, yksi tapahtumista peruutetaan, jolloin muut lukkiutumiseen liittyvät tapahtumat voivat valmistua. Uhrin valinta voi perustua transaktioiden arvoon tai vanhuuteen (Wait-Die ja Wound-wait -järjestelmät).
Jokainen kauppa T aikaleima on määritetty TS joka sisältää tapahtuman alkamisajan.
Odota-kuole.
Jos TS(Ti) < TS(Tj), Sitten Ti odottaa, muuten Ti rullaa taaksepäin ja aloittaa uudelleen samalla aikaleimalla.
Jos nuori tapahtuma on hankkinut resurssin ja vanhempi tapahtuma pyytää samaa resurssia, vanhempi tapahtuma saa odottaa. Jos vanhempi tapahtuma on hankkinut resurssin, sitä resurssia pyytänyt nuorempi tapahtuma peruutetaan.
Haava - odota.
Jos TS(Ti) < TS(Tj), Sitten Tj rullaa taaksepäin ja aloittaa uudelleen samalla aikaleimalla, muuten Ti odottaa.
Jos nuorempi tapahtuma on hankkinut resurssin ja vanhempi tapahtuma pyytää samaa resurssia, nuorempi tapahtuma peruutetaan. Jos vanhempi tapahtuma on hankkinut resurssin, sitä resurssia pyytävän nuoremman tapahtuman annetaan odottaa. Ensisijaisuuteen perustuva uhrien valinta estää lukkiutumisen, mutta peruuttaa tapahtumat, jotka eivät ole umpikujassa. Ongelmana on, että tapahtumat voidaan peruuttaa monta kertaa, koska... vanhempi tapahtuma saattaa säilyttää resurssin pitkään.
Pessimistinen ratkaisu lukkiutumisongelmaan ei salli tapahtuman aloittamista, jos on olemassa umpikujan riski.
Umpitilanteen havaitsemiseksi muodostetaan graafi (waiting graph, wait-for-graph), jonka kärjet ovat tapahtumia, ja reunat ohjataan tiedon luovuttamista odottavista tapahtumista tapahtumaan, joka on kaapannut nämä tiedot. Lukkiutumisen katsotaan tapahtuneen, jos graafissa on silmukka. Odotusgraafin rakentaminen, erityisesti hajautettuihin tietokantoihin, on kallis toimenpide.
Kaksivaiheinen lukitus – estää lukkiutumisen estämällä kaikki tapahtuman käyttämät resurssit tapahtuman alussa ja vapauttamalla ne lopussa
Kaikkien lukitustoimintojen tulee tapahtua ennen ensimmäistä lukituksen avaamista. Siinä on kaksi vaihetta - Kasvava vaihe, jonka aikana kahvat kerääntyvät, ja Shrinking Phase, jonka aikana kahvat vapautetaan. Jos jotakin resurssista ei voida kaapata, tapahtuma alkaa alusta. On mahdollista, että tapahtuma ei pysty hankkimaan tarvittavia resursseja esimerkiksi jos useat tapahtumat kilpailevat samoista resursseista.
Kaksivaiheinen toimitus varmistaa, että toimitus suoritetaan kaikissa tietokantakopioissa
Jokainen tietokanta syöttää tiedot muuttuvista tiedoista lokiin ja vastaa koordinaattorille OK (äänestysvaihe). Kun kaikki ovat vastanneet OK, koordinaattori lähettää signaalin, joka velvoittaa kaikki sitoutumaan. Sitoutumisen jälkeen palvelimet vastaavat OK; jos ainakin yksi ei vastaa OK, niin koordinaattori lähettää signaalin muutosten peruuttamiseksi kaikille palvelimille (Completion Phase).
Aikaleimamenetelmä
Vanhempi tapahtuma peruutetaan, kun yritetään päästä käsiksi nuorempaan tapahtumaan liittyviin tietoihin
Jokaiselle tapahtumalle on määritetty aikaleima TS joka vastaa suorituksen alkamisaikaa. Jos Ti vanhempi Tj, Sitten TS(Ti) < TS(Tj).
Kun tapahtuma peruutetaan, sille määritetään uusi aikaleima. Jokainen tietoobjekti Q tapahtumaan osallistuva on merkitty kahdella tarralla. W-TS(Q) — aikaleima nuorimmalle tapahtumalle, joka onnistui tietueessa Q. R-TS(Q) — nuorimman tapahtuman aikaleima, joka suoritti lukutallenteen Q.
Kun kauppa T pyytää tietojen lukemista Q kaksi vaihtoehtoa on mahdollista.
Jos TS(T) < W-TS(Q), eli tiedot päivitettiin nuoremmalla tapahtumalla, sitten tapahtumalla T rullaa takaisin.
Jos TS(T) >= W-TS(Q), sitten lukeminen suoritetaan ja R-TS(Q) on tulossa MAX(R-TS(Q), TS(T)).
Kun kauppa T pyytää tietojen muutoksia Q kaksi vaihtoehtoa on mahdollista.
Jos TS(T) < R-TS(Q), eli tiedot on jo lukenut nuoremman tapahtuman toimesta ja jos muutos tehdään, syntyy ristiriita. Tapahtuma T rullaa takaisin.
Jos TS(T) < W-TS(Q), eli tapahtuma yrittää korvata uudemman arvon, tapahtuma T peruutetaan. Muissa tapauksissa muutos suoritetaan ja W-TS(Q) tulee tasa-arvoiseksi TS(T).
Kallista odotuskaavion rakentamista ei tarvita. Vanhemmat tapahtumat riippuvat uudemmista, joten odotuskaaviossa ei ole jaksoja. Ei ole lukkiutumista, koska tapahtumia ei odoteta, vaan ne palautetaan välittömästi. CSS-palautukset ovat mahdollisia. Jos Ti rullasi pois ja Tj Luin muuttamani tiedot Ti, Sitten Tj pitäisi myös perääntyä. Jos samaan aikaan Tj on jo tehty, silloin vakauden periaatetta rikotaan.
Yksi ratkaisuista peräkkäiseen palautukseen. Tapahtuma suorittaa kaikki kirjoitustoiminnot lopussa, ja muiden tapahtumien on odotettava kyseisen toiminnon valmistumista. Tapahtumat odottavat sitoutumista ennen lukemista.
Thomasin kirjoitussääntö - muunnelma aikaleimamenetelmästä, jossa nuoremman tapahtuman päivittämät tiedot on kielletty vanhemman tapahtuman päällekirjoittamisesta
Tapahtuma T pyytää tietojen muutoksia Q. jos TS(T) < W-TS(Q), eli tapahtuma yrittää korvata uudemman arvon, tapahtumaa T ei peruuteta kuten aikaleimamenetelmässä.
Lähde: will.com