Samanaikaisuuden hallinta ohjelmoinnin näkökulmasta

1. Samanaikaisuuden hallintaohjelmoinnin näkökulmasta Tiedonhallintaa JaakkoRantanen 1. versio 14.9.1998 Päivitetty 11.3.2009 (huojo)

2. 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. Sarjallistuvuus TX1, TX2, TX3 • Sarjallinen (serial) ajoitustoimii 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 • 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 rollbacktai DBMSn suorittamaan automaattiseen peruutukseen, jos ei vahvistusta tule sovellus TX DBMS

5. Atomisuus • Transaktio suoritetaan aina jakamattomana eli atomisena (atomic) Kaikki tai ei mitään!

6. 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 komentoset autocommit off

7. 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 • 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. 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 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 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) 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 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) 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) 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. SQL-92 Isolation levels • Eristyvyystasojen määritelmät Dirty Read Nonrepeatable Read Phantoms READ UNCOMMITTED mahdollinen mahdollinen mahdollinen Ei mahdollinen mahdollinen mahdollinen READ COMMITTED REPEATABLE READ Ei mahdollinen Ei mahdollinen mahdollinen SERIALIZABLE Ei mahdollinen Ei mahdollinen Ei mahdollinen

18. Käyttö ohjelmassa • Transaktiokohtaisesti voi antaa komennonset transaction isolation level ohjelmassa tehtävän vaatimuksen mukaan readuncommitted readcommitted repeatableread serializable

19. 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. TX1 TX2 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 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 • 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 erojaLä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 • 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 • 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, muutaloittakoot 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"