Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta

Esitys aiheesta: "Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta"— Esityksen transkriptio:

1 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Tiedonhallintaa Jaakko Rantanen 1. versio Päivitetty (huojo)

2 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Samanaikaisuus Yhden vai monen asiakkaan palvelu Tapahtumat voivat olla sarjallisia (serial), ts.kukin tapahtuma joutuu odottamaan edellisen päättymistä. Sarjallisessa suorittamisessa samanaikaisuusaste on yksi (1), ts. pystytään suorittamaan vain yhtä tapahtumaa kerrallaan. Alkeellinen ohjelmointimenettely olisi kokonaisen tiedoston tai tietokannan taulun lukinta sovelluksesta esimerkiksi lock-komennolla, mikä ei kelpaa tietokantapalvelimen käytössä!

3 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Sarjallistuvuus TX1, TX2, TX3 Sarjallinen (serial) ajoitus toimii kuin "köyhän talon porsaat", mutta siinä on vain yksi samanaikainen asiakas. Tapahtumajoukon TX1, TX2,... ajoitus on sarjallistuva (serializable), jos se tuottaa saman eheän lopputuloksen kuin jokin sarjallinen ajoitus (kaikista eri järjestysvaihtoehdoista). Voi olla monta samanaikaista asiakasta. Tällä on vankka teoreettinen tausta, jota ei nyt tarkastella lähemmin.

4 Transaktio sovelluksessa
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Transaktio sovelluksessa Transaktion alku on joko eksplisiittinen: komento begin transaction implisiittinen: ei komentoa, vaan ohjelman(osan) käynnistys tai edellisen transaktion päättyminen Transaktio päättyy joko vahvistukseen: komento commit peruutukseen: komentoon rollback tai DBMSn suorittamaan automaattiseen peruutukseen, jos ei vahvistusta tule sovellus TX DBMS

5 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Atomisuus Transaktio suoritetaan aina jakamattomana eli atomisena (atomic) Kaikki tai ei mitään!

6 Transaktioita käytettävä
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Transaktioita käytettävä VARO! Mm. ODBC ja JDBC, Accessin Jet Engine,... käyttävät autocommit -tilamuuttujaa, jonka arvot ovat on tai off. Oletusarvo on on. Autocommit ei sovi normaaliin sovellukseen Yleensä on annettava aluksi komento set autocommit off

7 Miten kävisi tilisiirrossa?
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Miten kävisi tilisiirrossa? set autocommit on !!! lue tilin tA saldo sA kirjoita sA = sA-100 lue tilin tB saldo sB linjahäiriö/system crash/... kirjoita sB = sB+100

8 Transaktiot ja luokkien palvelut
Operaatioiden eli palvelupyyntöjen suunnittelussa on transaktioeheys säilytettävä Useimmiten luonnollisina tehtävinä TILI numero saldo hae() muuta() TILI numero saldo siirto(tilille, rahaMäärä)

9 Samanaikaisuuden hallinnan toteutustekniikoita
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Samanaikaisuuden hallinnan toteutustekniikoita DBMSien tarjoamat toteutustavat: lukitus versiointi Itse ohjelmoitu toteutustapa: aikaleimojen hallinta tarpeelliseksi katsotut tiedon osat (esim. rivi) varustetaan aikaleima-sarakkeella (on myös ylläpidettävä) jokaisen luku- ja päivityskäskyn yhteydessä päätellään aikaleimoista onko joku muu ollut käsittelemässä ko. tietoja samaan aikaan Tässä yhteydessä ei käsitellä aikaleimoilla ohjelmointia lähemmin.

10 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Transaktion hallinta Tapahtumien samanaikaisuutta (concurrency) hallitsee tietokantapalvelin sekä mahdollinen tapahtumanhallinta-ohjelmisto (CICS, MTS, Tuxedo, M3,...) Sovellus pyytää tietokantapalvelimelta tai tapahtumanhallintajärjestelmältä tehtäväänsä sopivaa eristyvyystasoa (Isolation Level). Eristyvyystaso ilmaisee transaktion eristyvyyttä eli riippumattomuutta muista samanaikaisista transaktioista (tapahtumista).

11 Samanaikaisuuden ongelmat, by Chris Date
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Samanaikaisuuden ongelmat, by Chris Date Tyypilliset ongelmatilanteet (anomalies): 1 Hukatun päivityksen ongelma (lost update) päällekirjoitus 2 Keskeneräisen käsittelyn ongelma (uncommitted dependency) a) luetaan peruutettava b) päivitetään peruutettava 3 Ristiriitaisen tulkinnan ongelma (inconsistent analysis) a) eritahtinen päivitys b) uusien rivien ongelma (phantom rows)

12 1) Hukatun päivityksen ongelma
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta 1) Hukatun päivityksen ongelma Tili X, saldo 1000 Transaktio A ”nostan 200 €” Transaktio B ”nostan 500 €” lue tili X lue tili X Saldo = saldo - 200 Saldo = saldo - 500 Kirjoita tili x Kirjoita tili x aika Aina estettävä

13 2 a) Keskeneräisen luku (dirty read)
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta 2 a) Keskeneräisen luku (dirty read) Tili X, saldo 1000 Transaktio A ”katson saldon” Transaktio B ”nostan 500 €” lue tili X Saldo = saldo - 500 kirjoita tili X lue tili X ROLLBACK aika "Dirty read"

14 2 b) Keskeneräisen päivitys
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta 2 b) Keskeneräisen päivitys Tili X, saldo 1000 Transaktio A ”nostan 200 €” Transaktio B ”nostan 500 €” lue tili X Saldo = saldo - 500 lue tili X ROLLBACK Saldo = saldo - 200 Kirjoita tili x aika Aina estettävä

15 3 a) Eritahtinen päivitys (nonrepeatable read)
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta 3 a) Eritahtinen päivitys (nonrepeatable read) Tili 1, saldo 1000 Tili 2, saldo 2000 Tili 3, saldo 5000 Transaktio A ”Tilien 1,2 ja 3 saldojen summa” Transaktio B ”siirrän 500 € tililtä 3 tilille 1” lue tili 1 summa = saldo lue tili 2 lue tili 3 summa = summa+saldo Saldo = saldo - 500 kirjoita tili 1 Saldo = saldo + 500 lue tili 3 COMMIT summa = summa+saldo aika "Nonrepeatable read"

16 3 b) Uusien rivien ongelma (phantom)
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta 3 b) Uusien rivien ongelma (phantom) Tili 1, saldo 1000 ... Tili 4, saldo 2000 Tili 5, saldo 5000 Transaktio A ”Tilien 1-N saldojen summa” Transaktio B X:”avaan tilin 2 ja talletan 1000€” lue tili 1 summa = saldo perusta tili 2 lue tili 4 saldo = 1000 summa = summa+saldo kirjoita tili 2 COMMIT lue tili 5 summa = summa+saldo aika "Phantom"

17 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
SQL-92 Isolation levels Eristyvyystasojen määritelmät Dirty Read Nonrepeatable Read Phantoms READ UNCOMMITTED mahdollinen mahdollinen mahdollinen READ COMMITTED Ei mahdollinen mahdollinen mahdollinen REPEATABLE READ Ei mahdollinen Ei mahdollinen mahdollinen SERIALIZABLE Ei mahdollinen Ei mahdollinen Ei mahdollinen

18 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Käyttö ohjelmassa Transaktiokohtaisesti voi antaa komennon set transaction isolation level ohjelmassa tehtävän vaatimuksen mukaan read uncommitted read committed repeatable read serializable

19 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Tekniikkana lukitus DBMS voi hallita samanaikaisuutta esim. lukitsemalla tietoja (nk. pessimistinen menetelmä). Lukon piirteitä: aste (yksityinen/jaettu/...), rakeisuus (predikaatti/rivi/sivu/taulu), ym. lukulukko on jaettu (S shared), muut saavat lukea, kirjoituslukko yksityinen (X exclusive), poissulkeva. Käytännössä vanhin ja yleisin tekniikka Tuotteiden toteutuksissa merkittäviä eroja mm. tehokkuudessa ja muistin käytössä

20 Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta
Lukkiuma Lukkiuma eli lukkiutuma (deadlock) voi syntyä, jos nk. odotusverkossa on sykli: Syklissä voi olla useitakin transaktioita Purku: DBMS valitsee uhri-transaktion ja pysäyttää sen TX1 TX2 nk. "wait-for-graph" TX1 on lukinnut tiedon X ja haluaisi tiedon Y TX2 on lukinnut tiedon Y ja haluaisi tiedon X

21 Lukkiumaan varautuminen
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Lukkiumaan varautuminen Entä jos oma ohjelma joutuu uhriksi? DBMS antaa uhrille SQLSTATE-koodin Transaktion ohjelmoinnissa pitää tutkia SQLSTATE ja varautua käynnistykseen on tiedettävä pitääkö käynnistyä itse uudelleen vai käynnistääkö ajoympäristö (esim. jokin TX Manager) Tuotteiden toteutuksissa pahoja eroja Lähes kaikki DBMSt tekevät uhri-transaktiolle rollbackin, mutta esim. Oracle7 peruu vain uhrin viimeisen käskyn! (Miten ohjelmoijan on osattava tähän Oraclen tilanteeseen varautua?)

22 Kaksivaiheinen lukitseminen
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Kaksivaiheinen lukitseminen Kaksivaiheinen lukituskäytäntö (2PL = two phase locking) tarkoittaa lukkiumia torjuvaa ohjelman suoritustapaa Transaktio TX noudattaa 2PL-käytäntöä, jos kaikki lukitusoperaatiot TXssa edeltävät ensimmäistä lukon vapautusta Käytännössä vähintään repeatable read  kaikki lukot pidetään commitiin asti. Tämä on nk. ankara (strict) 2PL.

23 Tekniikkana versiointi
Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta Tekniikkana versiointi Jokainen transaktio käsittelee omaa versiotaan (eli omaa kopiota) datasta. Vasta commit-hetkellä DBMS ilmoittaa mahdollisen konfliktin: että joku muu on ehtinyt muuttaa "originaali"dataa Nopein voittakoon, muut aloittakoot alusta! Kyky uudelleenaloitukseen konfliktin jälkeen on toteutettava ohjelman rakenteeseen. Versiointi on optimistinen menetelmä "eihän nyt tule konfliktia", lukinta pessimistinen "kumminkin nyt tulee konflikti"