Management of real-time replicated databases

КОРКГЛKOULU IALON KIRJASTO .TIE 2

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

Timo Jantunen

REAALIAIKAISEN MONISTETUN TIETOKANNAN HAJAUTUKSEN HALLINTA

DIPLOMITYÖ

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä:

Työn nimi:

Päivämäärä:

Timo Jantunen

Reaaliaikaisen monistetun tietokannan hajautuksen hallinta 02.12.1998

Työn sivumäärä: 48 Osasto:

Professuuri:

Tietotekniikan osasto / Ohjelmistotekniikka Tik-76 Ohjelmistojärjestelmät

Työn valvoja:

Työn ohjaaja:

Professori Reijo Sulonen, Teknillinen Korkeakoulu Diplomi-insinööri Jyrki Tunnela, Tekla Oy

Yhä suuremmat tietokannoille asetetut suorituskykyvaatimukset ovat pakotta­

neet tietokantajärjestelmien suunnittelijat tutkimaan erilaisia hajautettuja tie­

tokantoja. Koska hajautettujen tietokantojen ongelmaan ei ole olemassa yleistä ratkaisua, erilaisia ongelmia varten on yleensä suunniteltava oma rää­

tälöity menetelmä.

Tässä diplomityössä on kehitetty ohjelmisto vastaamaan tietokannan monis­

tamisesta usean eri tietokantasolmun välillä. Vaatimuksena oli mahdollisim­

man suuri suorituskyky koko tietokantaverkossa yleensä, sekä paikallisissa solmuissa erityisesti. Tutkittu tietokanta ei sisältänyt eheysrajoitteita ja eri tie- tokantakohteiden väliset ristiviittaukset olivat harvinaisia. Suurin ongelma tie­

tojen eheyden kannalta oli, että solmujen piti sekä pystyä toimimaan itsenäisesti tietoliikenneyhteyksien ollessa poikki että kyetä palaamaan verk­

koon ilman koko järjestelmän uudelleenkäynnistystä.

Työssä kuvataan hajautinjärjestelmän suunnittelua ja toteutusta, sekä järjes­

telmän toimiessa normaalisti että sen toipuessa tietoliikenneyhteyskatkoista.

Lopuksi tarkastellaan toteutetun järjestelmän kykyjä ja rajoituksia sekä jatko- kehitysmahdollisuuksia.

Avainsanat: Monistetut tietokannat, reaaliaikaisuus, monisäikeinen ohjel­

mointi.

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER’S THESIS

Author:

Name of thesis:

Date:

Timo Jantunen

Management of real-time replicated databases Dec 2, 1998

Number of pages: 48 Faculty:

Professorship:

Information Technology / Software Engineering Tik-76 Software Engineering

Supervisor:

Instructor:

Professor Reijo Sulonen, Helsinki University of Technology

M. Sc. (Eng.) Jyrki Tunnela, Tekla Oy

Increasing demands on databases have compelled their developers to research different kinds of distributed databases. However, as no general solution exists for the problems of distributed database systems, most problems need to be solved individually.

This master’s thesis presents a software system, which replicates a database between several database nodes. The main demand for the system was greatest possible performance for the database net in general and in local nodes in particular. The database in question did not have any integrity constraints and had only a minimal amount of cross-references. The biggest problem in database integrity was that nodes needed to be able to function independently even if communications to other nodes were unavailable and the system also needed to be able to reconnect these nodes to the net without restarting the whole system.

This thesis describes the design and implementation of the database system both when it functions normally and when it is recovering from communication problems. Finally, the abilities, limitations and need for further development of the system are considered.

Keywords: Replicated databases, real-time, multithreaded programming.

ALKUSANAT

Diplomityö on tehty Tekla Oy:n Projektiliiketoiminnan yksikössä opinnäytteeksi TKK:n tietotekniikan osastolle professori Reijo Sulosen valvomana. Haluan esittää hänelle kiitokseni saamis­

tani rakentavista kommenteista ja parannusehdotuksista.

Lisäksi haluan kiittää työni ohjaajaa Jyrki Tunnelaa kaikista saa­

mistani ohjeista ja neuvoista sekä oikolukijoitani Outi Tunnelaa ja Elina Ekolaa. Lopuksi haluan kiittää muita työtovereitani hyvästä työympäristöstä.

Espoossa 2. joulukuuta 1998

Timo Jantunen

SISÄLLYSLUETTELO

1 Johdanto... 5

1.1 Historiaa...5

1.2 Suorituskyvyn tavoittelu... 5

1.3 Tämänhetkisiä kehityssuuntia...7

1.3.1 Itsenäinen toipuminen... 7

1.3.2 Kaksitasoinen sarjallistuvuus... 8

1.3.3 Rajoitettu tietämättömyys... 8

2 Tavoitteet... 10

2.1 Taustaa...10

2.1.1 Tietokantojen yleisiä ominaisuuksia...10

2.1.2 Ympäristö... 10

2.1.3 Tietokannan rakenne... 11

2.1.4 Tietojen käyttötavat... 12

2.2 Vaatimuksia... 13

3 Suunnittelu... 15

3.1 Perusrakenne... 15

3.2 MT-safe ohjelmointi...16

3.2.1 Jaettujen tietojen suojaus...16

3.2.2 Lukitusten käyttö... 16

3.2.3 Semaforit... 17

3.3 Apufunktiot...17

3.3.1 Monisäikeinen sovellus... 17

3.3.2 Rengaspuskurit...17

3.3.3 Jonot... 18

3.3.4 Listat... 18

3.3.5 Muut apufunktiot... 19

3.4 Hajautinverkon rakenne... 19

3.4.1 Transaktiopaketit... 20

3.4.2 Komentopaketit... 20

3.5 Kommunikointi... 20

3.5.1 Normaalitila...21

3.5.2 Yhteydenmuodostaminen... 21

3.5.3 Kättelijä...22

3.5.4 Keskustelun aloitus... 22

3.5.5 Toipuminen...22

3.5.6 Komennot...24

3.6 Säikeiden tilat... 24

3.6.1 GW-säie... 25

3.6.2 Ydinsäie...27

4 Toteutus...29

4.1 Perusrakenne... 29

4.1.1 Käytetyt kirjastot... 29

4.2 MT-safe -ohjelmointi...30

4.3 Apufunktiot... 31

4.3.1 Säikeiden hallinta... 31

4.3.2 Rengaspuskurit... 32

4.3.3 Jonot... 35

4.3.4 Listat... 36

4.3.5 Muut apufunktiot... 37

4.4 Hajautinverkon rakenne... 38

4.4.1 Hajautinpakettien tietorakenne... 38

4.4.2 Transaktiopaketit... 39

4.4.3 Komentopaketit... 39

4.5 Kommunikointi... 39

4.5.1 Yhteyden muodostaminen... 40

4.5.2 Kättelijä...40

4.5.3 Keskustelun aloitus... 40

4.5.4 Toipuminen...41

4.5.5 Komennot...42

4.6 Säikeiden tilat... 43

4.6.1 GW-säie...43

4.6.2 Ydinsäie... 43

4.7 Korkeamman tason logiikka...43

5 Tulokset...44

5.1 Kokemukset... 44

5.2 ACID ominaisuudet...45

5.3 Jatkokehitys... 46

6 Viitteet...47

TYÖSSÄ KÄYTETYT TERMIT JA LYHENTEET

Asynkroninen

Atominen

Blocking

DBfast GISbase GUI GW-säie Hajautin

ID I/O IP

Lukkiuma

MT

MT-safe

Nonblocking

Reaalikanta Reaalitaulu Rivi

Sarake

Tiedonsiirtotapa, jossa vastapuolelta ei odoteta välittömiä vastauksia lähetettyihin paketteihin.

Menetelmä lisää tiedonsiirron nopeutta tapauksissa, joissa vastapuoli on hidas tai tiedonsiirron vasteaika on suuri.

Jakamaton. Tapahtuma tai operaatio, jonka aikana ei ole mahdollista tapahtua mitään tapahtumaan liit­

tymättömiä tapahtumia tai operaatioita.

Soketin tila, jossa kaikki siihen osoitetut funktiokut­

sut palaavat vasta, kun operaatio on saatu suorite­

tuksi loppuun, tai operaation suorituksessa on tapahtunut virhe.

Kirjasto yksinkertaisten ja nopeiden tietokantojen toteuttamiseen keskusmuistissa. Osa GISbasea.

Tekla Oy:n kehittämä paikkatiedonhallintasovellus- ten tekemiseen erikoistunut ohjelmakirjasto.

Graphical User Interface. Graafinen käyttöliittymä.

Hajauttimen säie, joka kommunikoi toiseen sol­

muun. GW-säikeitä on yksi jokaista yhteyttä kohden.

Nimitys järjestelmän asiakasohjelmalle, joka jakaa solmun tiedot muille solmuille. Tämän diplomityön aihe.

Tietokantarivin tai muun kohteen yksilöivä tunniste.

Input/Output. Tiedonsiirto sisään/ulos.

Internet Protocol [1]. Internetin matalan tason tie­

donsiirtoprotokolla.

Deadlock. Tila, jossa vähintään kaksi säiettä yrittä­

vät lukita ristiin toistensa lukitsemia lukkoja eivätkä pääse etenemään.

Multi Thread. Monisäikeinen, prosessi sisältää use­

amman säikeen, joita ajetaan toisistaan riippumatta.

Monisäieturvallinen. Funktio tai kirjasto, jota voi käyttää monisäikeisestä ohjelmasta ilman erikoisjär­

jestelyjä.

Soketin tila, jossa kaikki siihen osoitetut funktiokut­

sut palaavat välittömästi, vaikka operaatiota ei olisi­

kaan saatu suoritettua loppuun.

Normaali levymuistia käyttävä tietokanta.

Taulu reaalikannassa.

Tietokantarivi. Rivi koostuu yhdestä tai useammasta sarakkeesta. Relaatiotietokannassa pienin talletet­

tava yksikkö.

Tietokantarivin osa. Riviin kuuluvan tietoalkion tal­

lennuspaikka.

Sarjailistuvuus

Semafori

Socket, soketti Synkroninen

Taulu TCP

Tekla Oy Telnet Tietokanta Transaktio UDP

Vasteaika

Virtuaalikanta

Virtuaalitaulu Ydin

Transaktion ominaisuus, joka määrää, että usean peräkkäisen tai yhtäaikaisen transaktion jälkeen on tietokannan tilan muutosta tutkimalla mahdollista löytää järjestys missä transaktiot ovat tapahtuneet.

Rakenne, jolla monisäikeiset ohjelmat voivat rajoit­

taa rajallisten resurssien käyttöä.

Kommunikaatioväylä tietokoneen ja tietoverkon välillä.

Tiedonsiirtotapa, jossa vastapuolelta odotetaan vas­

tausta jokaisen paketin lähettämisen jälkeen. Mene­

telmä parantaa vasteaikaa tapauksissa, joissa vastausta tarvitaan paikallisen toiminnan jatkami­

seksi.

Tietokantataulu. Kokoelma sarakkeiltaan samanlai­

sia tietokantarivejä.

Transmission Control Protocol [2]. Internetissä käy­

tetty luotettava tiedonsiirtoprotokolla.

Tekla Oy on paikkatietojärjestelmien kokonaisratkai­

suja toteuttava suomalainen ohjelmistotalo.

Tekstipohjainen yhteysohjelma eri tietokoneiden välillä.

Kokoelma toisiinsa liittyviä tietoja. Relaatiotietokan­

nat muodostuvat kokoelmasta tauluja.

Yksittäinen tietokannan tilaa muuttava kokoelma operaatioita.

User Datagram Protocol [3]. Internetissä käytetty epäluotettava (mutta tehokas) tiedonsiirtoprotokolla.

Aika, joka kuluu kysymyksen lähettämisestä vasta­

uksen saamiseen.

GISbasen keskusmuistissa oleva tietokanta. Tieto­

kantaan voi liittyä reaalikantataulu, jota päivitetään virtuaalikantaan tulevien muutosten perusteella, tai kyseessä voi olla puhtaasti virtuaalinen kanta ilman maalitauluja.

Taulu virtuaalikannassa.

Yleisnimi projektin olemassa olevalle funktiorajapin- nalle.

Ydinsäie

Hajauttimen prosessin "alkuperäinen" säie. Ainoa säie, josta voidaan käyttää ytimen funktioita.

Yksilöllinen indeksi

Taulukohtainen yhden tai useamman sarakkeen muodostama hakemisto. Hakemistossa (ja siten koko taulussa) ei voi olla kahta riviä, joilla kyseiset sarakkeet sisältäisivät samat arvot.

1 JOHDANTO

1.1 Historiaa

Tietokantojen - kuten tietokoneidenkin - historia on lyhyt, mutta niiden kehitys on nopeaa. Tietokoneita on käytetty tietokantojen käsittelyyn jo ennen 70-lukua, jol­

loin tietokannat perustuivat useimmiten verkko- ja hierarkkisiin tietomalleihin, mutta 70-luvulla tietokantojen käyttö alkoi varsinaisesti yleistyä. Tämän mahdol­

listivat sekä tietokoneiden kasvanut tiedonkäsittelykyky että massamuistivälinei- den kehitys.

Samoihin aikoihin kehitettiin myös tietokantojen käsittelyä tukeva relaatiomalli.

Relaatiotietokannat perustuvat tauluihin ja niiden välisiin yhteyksiin (relation).

Taulujen tiedot koostuvat taulun sisällä vakiomuotoisista riveistä, joissa taas voi olla useita sarakkeita. Eri taulujen rivien keskinäiset suhteet rakentuvat sarakkei­

den avainkenttien viittauksista toisiinsa. Relaatiokantojen kehitystä ja käyttöä tukivat myös 70-luvun loppupuolella kehitetyt tietomallit, erityisesti ER-malli (Entity-Relationship, [4]).

Relaatiotietokantojen jälkeen tietokantojen kehitys on keskittynyt lähinnä olio­

pohjaisiin tietokantoihin. Oliopohjaiset tietokannat tarjoavat enemmän jousta­

vuutta joihinkin käyttötarkoituksiin, mutta ne voivat olla tarpeettoman monimutkaisia käytettäviksi kaikissa järjestelmissä.

Tämän päivän kaupalliset tietokantaohjelmistot perustuvat lähes kaikki relaatio- tietokantamalliin, vaikka niissä saattaakin olla oliopohjaisia piirteitä. Relaatiotie­

tokantojen etuna ovat kohtalaisen hyvin standardoitu kyselykieli (SQL, [5]) ja erittäin pitkälle kehittyneet tietokantaoperaatioiden optimointialgoritmit.

Kattavan yleiskatsauksen tietokannoista voi lukea esimerkiksi viitteestä [6].

1.2 Suorituskyvyn tavoittelu

Viime aikoina eri tietokantajärjestelmille asetetut suorituskykyvaatimukset ovat kasvaneet ja yhtenä tutkimuksen kohteena ovat olleet hajautetut ja monistetut tietokannat. Näihin vaihtoehtoihin voidaan päätyä esimerkiksi tilanteissa, joissa tietokantaa tai sen osia tarvitaan useissa eri paikoissa ja paikkojen välinen tie­

donsiirtoyhteys tai käytössä oleva tietokonekapasiteetti ei ole riittävä, jotta tieto­

kantaa voitaisiin käyttää yhdestä keskuspalvelimesta. Toinen mahdollinen syy voi olla tarve taata edes rajoitettu toimintakyky muissa paikoissa, vaikka keskus- palvelin ei olisi toiminnassa tai siihen ei saataisi yhteyttä [7].

Laajalla alueella käytettävissä oleva tietokanta voidaan toteuttaa esimerkiksi seuraavilla tavoilla:

1. Yksi keskuspalvelin, johon kaikki operaatiot kohdistetaan.

2. Monta palvelinta, joilla kullakin on oma osansa tietokannasta.

Kaikki kyseiseen tietokannan osaan osoitetut operaatiot kohdiste­

taan sen omistavalle palvelimelle. Eri palvelimilla ei ole kopioita toistensa tiedoista.

3. Yksi keskuspalvelin, johon kaikki muutosoperaatiot kohdistetaan.

Muilla palvelimilla on tietokannasta ylimääräisiä, ainakin osittai­

sia, kopioita lukuoperaatioita varten. Keskuspalvelin välittää kaikki muutokset muille palvelimille.

4. Monta palvelinta, jotka omistavat osan tietokantaa. Palvelimet vastaavat yksin omistamiensa tietokannan osien päivityksistä.

Lisäksi muilla palvelimilla on vain lukuoperaatioihin tarkoitettuja, ainakin osittaisia kopioita tiedoista. Tiedoista vastaavat palveli­

met välittävät omistamiensa tietojen muutokset muille palveli­

mille. Tässä työssä omistajahajautetut tiedot liikkuvat tällä periaatteella.

5. Monta palvelinta, joilla on vähintään osittain päällekkäinen tieto­

kanta. Kaikki palvelimet voivat päivittää mitä tahansa osaa tieto­

kannasta. Tämän toteutustavan ilmentymää on käsitelty tässä diplomityössä.

Tapa 1 on yksinkertaisin ja takaa päivitysten konsistenttiuden ja sarjallistuvuu- den, kunhan itse transaktiot on rakennettu oikein. Toisaalta keskuspalvelimen tai sinne johtavien viestiyhteyksien riittämätön suorituskyky voi aiheuttaa järjestel­

män suorituskyvyn liiallista laskua. Kaikki lukitukset tapahtuvat yhden palvelimen sisällä ja ovat siten helpompia toteuttaa kuin useamman palvelimen tapauk­

sessa. Jos yhteys palvelimeen menetetään, järjestelmä on toimintakyvytön.

Jos tietokanta voidaan jakaa moneen osaan siten, että suurimmassa osassa yksittäisiä transaktioita on vain yhdessä osassa olevia tietoja, tavalla 2 voidaan pienentää suorituskyvyn pullonkauloja. Toisaalta monien eri palvelimien tietoihin kohdistuvista transaktioista aiheutuu ongelmia. Ratkaisuvaihtoehtoina on joko hyväksyä transaktion osat erikseen, jolloin on mahdollista, että transaktio hyväk­

sytään osittain, tai käyttää erilaisia lukitusmenetelmiä, jolloin menetetään ainakin osa monen palvelimen tuottamasta suorituskykyedusta. Lisäksi joissakin tieto­

kannoissa eri tietoalkioiden omistajapalvelimen selvittäminen voi olla hankalaa.

Jos yhteys yksittäiseen palvelimeen menetetään, järjestelmä voi silti toimia rajoi­

tetusti.

Jos suurin osa tietokantaoperaatioista on vain tiedon lukemista, tavalla 3 voi­

daan saavuttaa merkittäviäkin suorituskykyetuja. Tietokantaa muutettaessa lähetetään uudet tiedot keskuspalvelimelle joko lukiten ensin kaikki palvelimet tai lukiten vain keskuspalvelin. Ensimmäinen vaihtoehto heikentää tietokannan suo­

rituskykyä, toinen vaihtoehto taas saattaa johtaa tietokannan epäkonsistenttiin tilaan: huonolla ajoituksella jokin muu palvelin saattaa tehdä vanhaan tietoon perustuvan operaation, ennen kuin päivitys saapuu keskuspalvelimelta. Sekä nopea että varma vaihtoehto tietokannan päivitysoperaatioille o1"» toteuttaa trans­

aktiot siten, että varsinainen tietojen muutos tehdään vasta keskuspalvelimella,

eikä siten, että asiakasohjelma laskee itse uuden arvon ja päivittää sen palveli­

melle. Jos tietokannan muutos lasketaan vasta keskuspalvelimella kanta pysyy konsistenttina, mutta menetelmän toteutus lisää palvelinten ja asiakasohjelmien monimutkaisuutta. Joka tapauksessa järjestelmän toiminta lakkaa käytännössä kokonaan, mikäli yhteys keskuspalvelimeen menetetään.

Tapa 4 yhdistää tavat 2 ja 3, joten sillä on myös niiden edut ja haitat: Jos suurin osa muutoksista tapahtuu vain yhden palvelimen omistamille tiedoille, voidaan saavuttaa hyvä suorituskyky, vaikka lukuoperaatioihin tarvittaisiinkin laajempaa tietomäärää. Lisäksi palvelinyhteyskatkoissa on mahdollista säilyttää ainakin rajoitettu toimintakyky, vaikka sen palvelimen omistamia tietoja ei voidakaan muuttaa, johon yhteys menetettiin. Kyseisen palvelimen tietojen kopiot muilla palvelimilla voivat olla vanhentuneita, joten niiden käyttämisestä saattaa aiheu­

tua ongelmia. Tapaan 4 liittyvät myös tapojen 2 ja 3 ongelmat tiedon eheyden sekä tavan 2 ongelmat omistajapalvelinten selvittämisen suhteen.

Tapaa 5 voi olla lähes mahdotonta toteuttaa, jos halutaan transaktioiden täydelli­

nen konsistenttius ja sarjallistuvuus. Jotta ne voitaisiin saavuttaa, kaikki palveli­

met kyseisen transaktion tietoja sisältävät palvelimet olisi lukittava. Tämä voi kuitenkin olla niin hidasta, että nopeampaan ja parempaan tulokseen päästäisiin käyttämällä tapaa 3. Jos luovutaan verkonlaajuisesta transaktioiden sarjallistu- vuudesta, voidaan käyttää joitakin muita tiedon konsistenttiuden takaavia algorit­

mejä, kuten kaksivaiheista transaktion vahvistusta [8]. Monet tällaiset algoritmit toimivat kuitenkin huonosti verkoissa, jotka eivät ole täydellisen luotettavia [7].

Jos sen sijaan verkonlaajuisen sarjallistamisen lisäksi luovutaan myös epäkon- sistenttien transaktioiden estämisestä ja tyydytään syntyvien konfliktien ratkaise­

miseen, menetelmällä voidaan saavuttaa suuri suorituskyky. Menetelmän suurimpia ongelmia ovat juuri konfliktien ratkaiseminen ja toipuminen palveli­

mien välisistä yhteyskatkoista, jollei koko järjestelmää pysäytetä yhden palveli­

men kaatumisen vuoksi [7].

1.3 Tämänhetkisiä kehityssuuntia

Hajautetuista ja monistetuista tietokannoista on tehty useita eri tutkimuksia, joista monet tosin keskittyvät todistamaan, mikä ainakaan ei ole mahdollista.

Tutkimusten runsautta selittää osaltaan juuri se, ettei yleistä ratkaisua ole ole­

massa, vaan useimpiin ongelmiin on kehitettävä räätälöityjä ratkaisuja kuten tässä työssä. Viime aikoina tutkimuksia on tehty muun muassa itsenäisestä toi­

pumisesta, kaksitasoisesta sarjallistuvuudesta ja rajoitetusta tietämättömyy­

destä.

1.3.1 Itsenäinen toipuminen

Viitteessä [9] todistetaan, että on mahdollista rakentaa hajautettu tietokanta- verkko, jonka kaikki solmut voivat yksittäisestä virheestä riippumatta toipua itse­

näisesti, eli päätyä samaan tilaan kommunikoimatta minkään muun solmun kanssa. Toisaalta ei ole mahdollista rakentaa tietokantaverkkoa, joka pystyy

itsenäiseen toipumiseen, jos virheitä tapahtuu enemmän kuin yksi. Sama pätee myös, vaikka solmujen annettaisiin lähettää tietoja virheen jälkeen [10].

Tietokantaverkon jakautuminen useaan osaan on vielä hankalampi ongelma:

Verkon solmujen ei ole mahdollista toipua itsenäisesti edes yhdestä jakaantumi­

sesta [9]. Jos solmujen sallitaan lähettää viestejä jakaantuneen jälkeen, tieto- kantaverkon jakaantumisesta kahteen osaan voidaan selvitä. Toisaalta tämäkään ei auta tilanteissa, joissa tietokantaverkko jakaantuu useampaan kuin kahteen osaan [10].

1.3.2 Kaksitasoinen sarjallistuvuus

Yksi tapa lisätä monen palvelimen suorituskykyä on osittain luopua perinteisesti tietokannan konsistenttiuden säilymiseen liitetyistä sarjallistuvista transaktioista [11]. Kaksitasoinen sarjallistuvuus soveltuu tilanteisiin, joissa suuri osa transakti­

oista koskee vain yhtä tietokantasolmua. Menetelmä soveltuu erityisesti tilantei­

siin, joissa ennen vain itsenäisesti toimineet tietokantasolmut liitetään yhteen mutta solmujen väliset transaktiot ovat kohtalaisen harvinaisia.

Kaksitasoinen sarjallistuvuus asettaa joitakin rajoituksia sekä paikallisille että verkonlaajuisille transaktioille, mutta jos ne täytetään, on mahdollista tehdä sekä muista riippumattomia paikallisia transaktioita että moneen solmuun vaikuttavia verkonlaajuisia transaktioita ilman, että tietokannan eheys vaarantuu. Kaksita­

soinen sarjallistuvuus -menetelmä rajoittaa suurimmaksi osaksi vain transaktioi­

den rakentamista ja tietokannan eheysehtoja - sekä paikallisen että verkonlaajuisen tietokannan hallinta-algoritmi voidaan valita kohtalaisen vapaasti.

1.3.3 Rajoitettu tietämättömyys

Eräs tapa lisätä rinnakkaisuutta ja sitä kautta suorituskykyä on rajoitettu tietä­

mättömyys (Bounded Ignorance, [12]). Menetelmässä kaikki tietokannan solmut eivät välttämättä ole tietoisia toistensa tekemistä viimeisimmistä transaktioista.

Menetelmä soveltuu tilanteisiin, joissa tietokannan tilalla on eheysrajoitteita, kuten esimerkiksi paikanvarausjärjestelmissä, joissa varattujen paikkojen luku­

määrä ei saa ylittää olemassaolevien paikkojen määrää.

Rajoitetun tietämättömyyden menetelmällä voidaan tehdä useita toisistaan tietä­

mättömiä transaktioita siten, että tietokannan eheysrajoitteita ei ylitetä kovin pal­

jon. Käytännössä rajoitettu tietämättömyys tarjoaa varmuuden siitä, että N- tietämättömässä järjestelmässä voidaan käsitellä N+1 transaktiota samanaikai­

sesti ilman, että tietokannan eheysrajoitteita missään tilanteessa rikotaan enem­

pää kuin korkeintaan N kertaa. Tietokannan on joko kestettävä kyseinen ylitys esimerkiksi määrittelemällä rajoite todellista pienemmäksi tai toteuttamalla menetelmä konfliktien ratkaisemiseksi.

Rajoitettua tietämättömyyttä voidaan myös käyttää tilanteissa, joissa tietokan­

nalta vaaditaan viite-eheyttä. Tällaisissa tapauksissa rajoitettu tietämättömyys vähentää konfliktien syntymistä ja siten helpottaa niiden ratkaisemista. Yksi

mahdollinen menetelmä konfliktien ratkaisemiseksi on dynaaminen äänestämi­

nen eri tietokantasolmujen kesken [13].

2 TAVOITTEET

2.1 Taustaa

2.1.1 Tietokantojen yleisiä ominaisuuksia

Tietokantojen transaktioilta halutaan usein ACID-ominaisuuksia (Atomicity, Con­

sistency, Isolation, Durability).

Atomicity

Consistency

Isolation Durability

Atomisuus. Tietokantaan tehdyt transaktiot joko tapahtuvat kokonaan tai eivät tapahdu ollenkaan.

Lisäksi ulkopuolelta tarkasteltuna kaikki transaktion operaatiot tapahtuvat samalla hetkellä, eli transak­

tion vaiheet eivät näy muualle.

Ristiriidattomuus. Jos tietokanta on eheässä tilassa, jokainen laillinen transaktio siirtää sen toiseen ehe- ään tilaan.

Riippumattomuus. Jokainen transaktio käsitellään erillisenä, eivätkä ne vaikuta toisiinsa.

Pysyvyys. Jokainen hyväksytyn transaktion aiheut­

tama tietokantamuutos jää voimaan erilaisista myö­

hemmistä virhetilanteista huolimatta.

Koska kaikkien näiden ominaisuuksien toteuttaminen määritelmän mukaisessa reaaliaikaverkossa on mahdotonta, on tyydyttävä jonkinasteiseen osajoukkoon.

ACID-ominaisuuksien toteutumisiin palataan luvussa 5.

2.1.2 Ympäristö

Työssä tutkitaan relaatiotietokannan toteuttamista järjestelmässä, jossa samaa tietoa tarvitaan monessa fyysisesti ja topologisesti etäällä toisistaan olevassa solmussa. Sekä reaaliaikaisuusvaatimukset että eri solmujen välisten tietoliiken­

neyhteyksien suhteellinen hitaus pakottavat tutkimaan vaihtoehtoja, joissa sama tieto on saatavissa ja muutettavissa eri solmuissa paikallisesti. Tehtävää vai­

keuttaa se, että solmujen muodostaman verkon topologian pitää kyetä muuttu­

maan ilman järjestelmän uudelleenkäynnistämistä. Tämän ominaisuuden toteuttaminen vaatii, että verkkoon liittyvän solmun on kyettävä yhdistämään tie­

tokantansa muun verkon kanssa. Myös verkon jakaantumiseen moneen osaan pitää osata varautua.

Koska tietokannassa ei ole selkeästi erottuja tietoja, joita tarvitaan suurimmaksi osaksi vain yhdessä solmussa, ei osittain hajautettu tietokanta sovellu ongelman ratkaisuksi, vaan on lähdettävä suunnittelemaan monistettua tietokantaa. Toi­

saalta on olemassa myös tauluja, joiden kaikkia rivejä ei haluta jakaa muille sol­

muille, joten on toteutettava mahdollisuus suodattaa hajautettavia rivejä.

Tarkasteltavassa tietokannassa ei ole monimutkaisia riippuvuuksia eri taulujen välillä, ja suurinta osaa tiedoista muutetaan vain harvoin. Lisäksi osa tiedoista liittyy voimakkaasti yhteen solmuun, ja niiden virheetön jakaminen muihin sol­

muihin ei ole olennaista. Tällaisia tietoja jakavien taulujen hajautusperiaatteeksi määritellään rivikohtainen omistaja, muut tiedot hajautetaan aikaleimaan perus­

tuen.

Käytössä oleva laitteisto koostuu Sun-työasemista ja -palvelimista, joissa voi­

daan katsoa olevan sekä muistia että prosessoritehoa käytössä "riittävästi", mutta ei ylen määrin tuhlattavaksi, koska samoissa koneissa ajetaan myös muita sovelluksia samanaikaisesti.

Tiedonsiirto eri solmujen välillä tapahtuu TCP/IP-protokollaa käyttäen.

2.1.3 Tietokannan rakenne

Työn toteutus on suunniteltu käyttämään pohjana Teklan GISbase-työkaluja.

Käytännössä tämä tarkoittaa, että käytettävä tietokanta muodostuu reaali- ja vir- tuaaliosasta. Reaalikantana käytetään jotain tavallista, kaupallista relaatiotieto­

kantaa, josta suorituskykysyiden takia osa tauluista ladataan muistiin virtuaalikantaan ajon ajaksi. Osa tauluista on olemassa vain virtuaalikannassa ns. puhtaina virtuaalitauluina, joten niiden sisältämät tiedot menetetään, jos jär­

jestelmä ajetaan alas.

Puhtaina virtuaalitauluina käytetään tauluja, joihin tulee niin paljon muutoksia, että järjestelmän käynnistyksen yhteydessä reaalikannasta ladattavat tiedot oli­

sivat jo vanhentuneita. Puhtaisiin virtuaalitauluihin tulevat päivitykset ovat myös nopeampia, koska päivityksiä ei tarvitse siirtää hitaampaan reaalikantaan.

Toinen tilanne, joissa tauluja käsitellään puhtaina virtuaalitauluina on se, että tie­

dot muodostetaan käynnistyksen yhteydessä muista tauluista. Näiden taulujen sarakkeet ovat tyypillisesti johdettuja attribuutteja, jotka lasketaan joidenkin sovellusten toimintojen nopeuttamiseksi.

Samoin erilaisia hakemistorakenteita voidaan muodostaa vain virtuaalikantaan;

erityisesti paikkatiedonhallintasovellusten tekemisen avuksi kehitetty GISbase osaa esimerkiksi luoda erilaisia geometrisia hakemistoja.

Järjestelmän jo valmiit osat on toteutettu käyttäen asiakas-palvelin -arkkitehtuu­

ria, jossa yhden solmun sisällä samassa lähiverkossa toimii tietokantapalvelin, joka jakaa tietokantaa asiakasohjelmille. Suorituskykysyistä jokaisella asiakas­

ohjelmalla on oma kopio virtuaalitauluista lukuoperaatioita varten, mutta kaikki muutokset lähetetään palvelimelle, joka jakaa ne asiakasohjelmille. Koska yhden solmun koneet ovat samassa lähiverkossa tai jopa samassa koneessa, ei tästä aiheudu liian suuria viiveitä.

Samaa ratkaisua ei voida soveltaa solmujen välillä, koska niiden väliset tietolii­

kenneyhteydet ovat hitaampia ja epäluotettavampia, eikä yhden keskuspalveli­

men suorituskyky riittäisi palvelemaan monen eri solmun asiakasohjelmia.

Lisäksi tiedon käytettävyysvaatimukset määräävät, että eri solmujen on tarpeen vaatiessa kyettävä edes rajoitettuun toimintaan ilman yhteyksiä muualle. Tällöin vaihtoehtona palvelinten kompleksisuuden lisäämiselle on toteuttaa erillinen asi­

akassovellus, joka vastaa vaatimukset täyttävästä liikenteestä solmujen välillä.

2.1.4 Tietojen käyttötavat

Tietokannan tietomäärä jakautuu staattisiin, paikallisiin ja hajautettuihin tietoihin.

2.1.4.1 Staattiset tiedot

Staattiset tiedot ovat järjestelmän tietoja, jotka ovat kaikkialla samanlaisia eivätkä muutu kuin poikkeustapauksissa. Tällaisia tietoja ovat mm. solmujen nimet ja tietokantataulujen kuvaukset. Nämä tiedot eivät ole hajautuksen kan­

nalta merkittäviä, koska niiden mahdollisesti muuttuessa järjestelmä on ajettava alas. Niiden hajautusta vaativat muutokset on tehtävä muilla tavoilla, kuten ftp:llä tai jollakin fyysisellä medialla.

2.1.4.2 Paikalliset tiedot

Paikallisilla tiedoilla tarkoitetaan tietoja, joilla ei ole merkitystä solmun ulkopuo­

lella. Tällaisia tietoja ovat mm. paikalliseen parametrointiin liittyvät tiedot.

2.1.4.3 Hajautetut tiedot

Hajautettuja tietoja on kahta päätyyppiä: aikaleima- ja omistajahajautettuja.

Aikaleimahajautetuissa tauluissa oletetaan, että uudempi tieto on oikea. Aikalei- maa käytettäessä ongelmaksi tulee kellonaikojen samanlaisuus eri solmuissa, mutta koska yleisesti ottaen samoja tietoja muutetaan harvoin samanaikaisesti eri solmuista, kohtalaisen pienet erot kellonajoissa eivät aiheuta liikaa ongelmia.

Järjestelmän on kuitenkin syytä pystyä tarkistamaan kellonaikojen eron suuruus ja varoittamaan käyttäjiä liian suuresta erosta.

Omistajahajautetuissa tauluissa jokaisella rivillä on omistajasolmu, jolla olete­

taan olevan paras käsitys rivin tiedoista. Siltä varalta, että yhteys omistajasol- muun menetetään, pitää olla mekanismi omistajan vaihtamiseksi.

Näiden hajautustyyppien lisäksi päätettiin toteuttaa hajautusmenetelmä, joka nimettiin "nopeaksi aikaleimahajautukseksi". Nopeaa aikaleimahajautusta voi­

daan käyttää tiedoille, joihin tulee paljon päivityksiä, mutta joissa päivityksen satunnainen häviäminen ei haittaa. Tätä ominaisuutta voidaan hyödyntää tilan­

teissa, joissa tietoliikennekapasiteetti ei väliaikaisesti riitä siirtämään kaikkia päi­

vityksiä, tai toivuttaessa lyhyemmästä yhteyskatkosta, mitä voidaan nopeuttaa jättämällä väliin jo vanhentuneita päivityksiä.

Jos taulu on hajautettu mutta sellainen, että vain osa sen riveistä tai sarakkeista halutaan jaettavaksi muihin solmuihin, tarvitaan suotimia.

2.2 Vaatimuksia

Edellä kuvattu olemassa oleva järjestelmä asettaa suorasti tai epäsuorasti useita vaatimuksia. Funktionaalisia ja epäfunktionaalisia ominaisuuksia kuvataan seu- raavassa:

e

Tietokannan hajautus on toteutettava ennaltamääräämättömässä ja muuttuvassa verkossa.

• Järjestelmän pitää kyetä toipumaan "lyhyistä" yhteyskatkoista ilman, että sen toiminta häiriintyy.

• Järjestelmän piiriin pitää pystyä liittämään verkosta pidempään irti olleita tai uusia solmuja tai aliverkkoja ilman, että koko järjes­

telmä pitää uudelleenkäynnistää.

Tietokannassa on oltava aikaleima- ja omistajapohjaiset hajautusme- netelmät. Lisäksi on oltava mahdollisuus siirtää tietoa vain määräajoin.

Tietokannan hajautuksen on oltava mahdollisimman nopeaa suh­

teutettuna tietoliikennekapasiteettiin ja tietoliikenteeseen. Järjestelmän pitää kyetä havaitsemaan ja ainakin jollain tasolla selviämään tilan­

teista, joissa tietoliikennekapasiteetti ylitetään väliaikaisesti.

Järjestelmän on oltava mahdollisimman vikasietoinen huolimatta häiri­

öistä tietoliikenneyhteyksissä, virheellisestä parametroinnista, virheelli­

sestä käyttäjän toiminnasta ja toteutuksessa itsessään olevista virheistä.

• Järjestelmän on osattava tarkastaa parametrointinsa ja tarvitta­

essa epäillä käyttäjän antamien komentojen järkevyyttä.

• Ajonaikaisesti muodostettavia yhteyksiä tai niiden hajauttamien taulujen määrää tulee voida rajoittaa.

• Ohjelman on tarkkailtava myös omaa sisäistä toimintaansa.

• Ohjelman on parasta olla toimimatta ollenkaan tilanteissa, joissa se epäilee toimintansa järkevyyttä.

Järjestelmän tulee olla mahdollisimman yleinen siten, että järjestelmää muuttamatta voidaan vaihtaa taulujen kuvauksia tai hajautusmenetel- miä.

Parametrointia tulee voida muuttaa ilman järjestelmän uudelleenkäyn- nistämistä, ainakin yhteyksien ja niillä välitettävien taulujen määrän osalta.

Tiedoilla on oltava mahdollisimman suuri käytettävyys myös erikoisti­

lanteissa, jollei se vaaranna tiedon eheyttä.

Hajautusverkon tilasta on kerättävä tietoa, joka on pystyttävä esittä­

mään käyttäjälle.

On oltava mahdollista määritellä osa tauluista sellaisiksi, että niihin kohdistuneet päivitykset voidaan jättää väliin ilman virhetilannetta esi­

merkiksi väliaikaisissa ruuhkatilanteissa.

Toteutuksen on oltava siirrettävissä myös muille käyttöjärjestelmille.

Toteutuksen on varauduttava järjestelmän myöhempään laajentami­

seen.

3 SUUNNITTELU

Tässä luvussa pohditaan mahdollisia toteutusmenetelmiä hajauttimelle, joka täyttää edellisessä luvussa asetetut vaatimukset. Koska yleisenä suunnittelu- ja toteutusperiaatteena on mahdollisimman suuri luotettavuus, on moniin tilantei­

siin hyvä suunnitella ohjelman sisäisiä tarkistuksia. Näillä tarkistuksilla on pyrit­

tävä varmistamaan, että ohjelma ei toimi virheellisesti vaikka, siinä olisikin virheitä. Lisäksi tarkistukset auttavat virheen löytämisessä.

3.1 Perusrakenne

Toteutukselle asetettujen suorituskykyvaatimusten vuoksi tutkittiin vaihtoehtoja, joissa yhden solmun hajautin pystyy välittämään transaktioita mahdollisimman tehokkaasti muille solmuille. Tämän toteuttamiseksi tutkittiin kolmea eri vaihto­

ehtoa:

1. Normaali (ei monisäikeinen) C-ohjelma, joka käyttää nonblocking soketteja.

2. Monta erillistä C-ohjelmaa, yksi jokaista yhteyttä kohti, käynniste­

tään joko erikseen tai ensimmäinen monistaa itseään tarvittavat kerrat.

3. Monisäikeinen C-ohjelma.

Vaihtoehdon 1 etuna on, että vältytään eri prosessien tai säikeiden väliseltä kommunikaatiolta ja niistä johtuvista ongelmista. Toisaalta tässä vaihtoehdossa kaikki kommunikointifunktiot olisi ohjelmoitava siten, että jollei niiden välitön suo­

ritus ole mahdollista, voidaan operaatiota jatkaa myöhemmin. Lisäksi joissakin, etenkin reaalikantaan liittyvissä, ytimen operaatioissa voi esiintyä suuriakin viive­

itä, jotka siten voivat heijastua koko hajauttimen toimintaan.

Vaihtoehdossa 2 päästään eroon eri yhteyksien toisilleen aiheuttamista viiveistä, mutta vielä suuremmaksi ongelmaksi nousee saman solmun eri hajautinproses- sien välinen keskinäinen kommunikointi. Koska joissakin tilanteissa, kuten yhte- yskatkosta toipumisen yhteydessä, on tärkeää tietää koko solmun tila, pitäisi olla tapa tietää kaikkien muiden prosessien tila. Tällaisen kommunikaation toteutus sekä luotettavasti että siten, että se ei merkittävästi hidasta toimintaa, on hanka­

laa. Lisäksi hajautinprosessien käyttämät resurssit voivat muodostua merkittä­

viksi solmuissa, joilla on useita yhteyksiä muihin solmuihin.

Vaihtoehto 3 muistuttaa vaihtoehtoa 2, mutta koska kaikki säikeet ovat saman prosessin sisällä, on paljon helpompaa ylläpitää solmun hajautuksen kokonaisti­

laa. Uudeksi ongelmaksi muodostuu ydin, joka ei ole MT-safe. Käytännössä tämä tarkoittaa, että ytimen funktioita voidaan kutsua vain alkuperäisestä ydin- säikeestä. Myös MT-safe -ohjelmointi asettaa omat vaatimuksensa toteutuk­

selle.

Toteutuksen pohjaksi valittiin vaihtoehto 3, koska epäiltiin vaihtoehdon 1 tehok­

kuutta korkeasti kuormitetuissa tilanteissa. Lisäksi Solaris-ympäristö tukee moniprosessorikoneita, joten useampaa prosessia tai säiettä käyttävien toteu­

tustapojen tehokkuutta pystyttäisiin tarvittaessa lisäämään asentamalla ajoym­

päristön koneeseen useampia prosessoreja. Vaihtoehtojen 2 ja 3 ongelmista vaihtoehdon 3 ongelmat arvioitiin helpommin ratkaistaviksi, ja lisäksi vaihtoehto 3 vaatii vähemmän resuresseja kuin vaihtoehto 2.

Suunnittelussa päädyttiin tekemään yksi säie jokaista yhteyttä kohti ja rajapin­

naltaan mahdollisimman samankaltainen säie paikalliselle solmulle. Lisäksi tar­

vittiin muutama muu säie lähinnä yhteyksien hallitsemiseksi.

3.2 MT-safe ohjelmointi

Ohjelmoitaessa monisäikeisiä ohjelmia on otettava huomioon yleisiä rinnakkais­

ten järjestelmien tekemiseen liittyvät rajoitukset. Ohessa lyhyt johdanto, tarkem­

paa tietoa voi lukea useista aihetta käsittelevistä kirjoista, esimerkiksi viitteestä [15].

3.2.1 Jaettujen tietojen suojaus

Koska monisäikeisessä sovelluksessa on mahdollista lukea ja kirjoittaa samoja tietoja useasta eri säikeestä toisistaan riippumatta, pitää huolehtia siitä, että tie­

dot eivät joudu laittomaan tilaan. Yksi tapa tehdä tämä on eristää kaikki julkisten tietojen manipulointi lukituksilla siten, että vain yksi säie kerrallaan voi muuttaa tietoa.

Lukituksia ei tarvita luettaessa tietoa, jos tiedon luku on luonteeltaan atomista ja jos tietoa ei aiota muuttaa luetun arvon perusteella. Toisaalta tällaisessa tilan­

teessa on muistettava, että luettu arvo voi olla jo vanhentunut tilanteessa, jossa sitä käytetään. Kirjoittaessa lukituksia ei tarvita, jos kirjoitus on luonteeltaan ato­

mista ja jollei kirjoitettava arvo riipu jaettavista tiedoista.

Jos tarpeellisista lukituksista ei huolehdita, sovellus voi joutua laittomaan tilaan kahden eri säikeen muuttaessa samaa tietoa yhtäaikaa.

3.2.2 Lukitusten käyttö

Lukituksilla voidaan estää useiden säikeiden yhtäaikainen pääsy kriittiseen tie­

toon, mutta niidenkin käytössä on noudatettava sääntöjä, tärkeimpänä luk- kiumien välttäminen. Lukkiuma syntyy tilanteessa, jossa vähintään kaksi säiettä odottaa ristiin toisen lukitseman lukon avautumista. Lukkiuman syntymisen voi estää esimerkiksi lukitsemalla kaikki tarvittavat lukot aina samassa järjestyk­

sessä. Näin voidaan varmistaa, että ensimmäisen haluamansa lukon saanut säie saa aina ennemmin tai myöhemmin loputkin tarvitsemistaan lukoista.

Toinen lukituksiin liittyvä tekijä on yksittäisen lukon lukitsema tietomäärä. Jos lukoilla suojataan esimerkiksi tietokantataulun sisältö, voidaan lukoilla eristää joko koko tietokanta, kyseinen taulu tai vain tarvittavat rivit. Jos lukoilla eriste­

tään suuria kokonaisuuksia, menetetään monisäikeisen sovelluksen suoritusky­

kyä, koska toisiinsa liittymättömät tapahtumat ovat samassa kriittisessä osassa.

Jos taas toisaalta lukitukset tehdään hyvin pienille osa-alueille, lukkojen ylläpitä­

miseen tarvittavien resurssien määrä kasvaa. Lisäksi suuri lukkojen määrä voi vaikeuttaa lukkiumatilanteiden välttämistä.

3.2.3 Semaforit

Semaforeja voidaan käyttää esimerkiksi rajoittamaan resurssien käyttöä monisäikeisissä sovelluksissa. Semafori alustetaan kokonaislukuarvolla, jonka arvo ei ole negatiivinen. Siihen voidaan kohdistaa P() ja V() operaatiot: V() lisää semaforin arvoa yhdellä. P() tarkistaa, onko semaforin arvo suurempi kuin nolla.

Jos on niin PQ vähentään arvoa yhdellä, muussa tapauksessa P() jää odotta­

maan, kunnes arvo tulee suuremmaksi kuin nolla.

3.3 Apufunktiot

Sovellus jaetaan kahteen eri kirjastoon, joista toinen sisältää alemman tason funktiot ja toinen korkeamman logiikan. Jaon tarkoituksena on koodin modulari- soiminen ja testauksen helpottaminen, koska alemman tason kirjasto on mah­

dollista testata ilman ydintä. Kaikki alemman tason apufunktiot on toteutettava monisäieturvallisesti. Alemman tason rutiinien kuvaus on luvuissa 3.3.1-3.3.5.

3.3.1 Monisäikeinen sovellus

Toteutus on syytä aloittaa toteuttamalla säikeiden hallitsemisessa tarvittavat apufunktiot, jotka vastaavat säikeiden luomisesta, tuhoamisesta ja niiden väli­

sestä kommunikoinnista. Kaikki säiekohtainen tieto kerätään yhteen rakentee­

seen

(h_thread_t),

jota käytetään kaikissa säikeissä. Rakenne sisältää säikeen tyypin ja tilan lisäksi yleiskäyttöistä puskurimuistia ja myöhemmin määri­

teltäviä tietorakenteita.

3.3.2 Rengaspuskurit

Transaktioiden välitys monille muille solmuille vaatii ajoittain suuriakin määriä väliaikaista talletustilaa, joten päätettiin toteuttaa väliaikainen talletustila rengas- puskureilla. Rengaspuskuri soveltuu tilanteeseen myös siksi, että transaktioiden vaatimia muistialueiden varaukset ja vapautukset tapahtuvat samassa järjestyk­

sessä.

Toistuvat muistin varaukset ja vapautukset johtavat vapaan muistin pirstaloitumi- seen. Yksi rengaspuskureiden käytöstä seuraava hyöty onkin, että ylimääräistä muistin varaamista ja vapauttamista voidaan välttää. Muistin pirstaloitumista yri­

tetään välttää myös käyttämällä säiekohtaista puskurimuistia suurimpaan osaan muista väliaikaista muistia tarvitsevista operaatioista.

Rengaspuskurit

Normaalissa tapauk­

sessa sama transaktio välitetään usealle eri sol­

mulle, joten säikeisiin liit­

tyvät lähetysjonot suunniteltiin siten, että monta eri jonoa voi viitata samaan muistialueeseen.

Ohjelman sisäisen toimi­

vuuden varmistamiseksi ja jonojen ylivuotojen havaitsemiseksi rengas- puskurin on pidettävä kir­

jaa siihen liittyvistä viittauksista.

Rengaspuskurin sisäl­

löstä pidetään kirjaa DBfast-taulun avulla.

Taulu sisältää kaikki pus­

kurissa olevat transaktiot, myös ne, joihin ei ole enää viittauksia jonoissa.

Taulussa on tarpeelliset hakemistorakenteet tran­

saktion löytämiseksi pus­

kurista erilaisilla avaimilla, esimerkiksi

muistialueen osoitteen tai transaktion ID:n perusteella. Rengaspuskurin sisältöä voidaan käyttää myös yhteyskatkoksista toivuttaessa.

Jonot

3.3.3 Jonot

Jokaisella GW-säikeellä ja ydinsäikeellä on transaktiojono. Jonoon talletetaan järjestysnumero ja transaktion ID, itse transaktio talletetaan kuitenkin vain ker­

taalleen yhteiseen rengaspuskuriin. Jonoon toteutetaan normaalien lisäys-, haku- ja palautusfunktioiden lisäksi funktioita, joiden avulla jonosta voidaan pois­

taa transaktioita ID:n perusteella ja selvittää, onko jonon viittaama transaktio vielä saatavilla rengaspuskurista vai ylivuotanut.

3.3.4 Listat

Lisäksi toteutetaan listaksi kutsuttu yksinkertainen tietovarasto, johon voi tallet­

taa ainutkertaisen ID:n ja sen lisäksi joko kokonaisluvun tai osoittimien. Listaan pystyy kohdistamaan monipuolisia operaatioita, kuten lisäys, poisto, haku, kopi­

ointi joko taulukkoon tai toiseen listaan ja olemassaolon tarkistus. Listoja käyte­

tään useissa eri paikoissa väliaikaisena tietovarastona, missä niiden dynaaminen muistin varaus ja MT-safe -operaatiot yksinkertaistavat operaatioita

ja varmistavat, että ylivuotoja tai yhtäaikaisesta käsittelystä johtuvia korruptoitu­

misia ei tapahdu.

3.3.5 Muut apufunktiot

Apufunktioiden moduuliin kuuluvat lisäksi alemman tason funktiot, joiden avulla voidaan tulostaa tila- ja testausdataa joko konsolille tai ytimen käyttöliittymälle.

Lisäksi suunniteltiin funktio, jonka avulla mikä tahansa säie pystyy antamaan ydinsäikeen suoritettavaksi funktion.

3.4 Hajautinverkon rakenne

Hajautin Hajautin

Hajautin Hajautin

Kuva 3.1 Hajautinverkon rakenne

Hajautinverkko muodostuu hajautinprosessien eri solmujen välisistä yhteyksistä.

Rakenne on esitetty kuvassa 3.1. Kuvassa S tarkoittaa solmun paikallista tieto­

kantapalvelinta ja C muuta paikallista asiakassovellusta, kuin hajautinta.

Esiteltyyn rakenteeseen päädyttiin, koska tällä järjestelyllä paikallisen solmun tiedon käsittely ei hidasta transaktioiden välitystä muille solmuille. GW-säikeiden riippumattomuus ytimestä takaa niiden toiminnan myös monissa paikallisen sol­

mun virhetilanteissa. Järjestelmä auttaa myös paikallisen solmun tiedon käsitte­

lyssä, koska ydinsäikeellä on samanlainen transaktiojono kuin GVV-säikeilläkin.

Näin ydinsäikeen ei tarvitse jatkuvasti olla odottamassa uusia transaktioita hajautinverkosta, vaan jonossa olevat transaktiot voidaan käsitellä vain aika- ajoin. Samalla myös suotimien toteutus helpottuu, koska ne voidaan ajaa ydin- säikeessä ilman erityisjärjestelyjä.

Solmujen välisessä liikenteessä käytetään paketteihin perustuvaa asynkronista liikennettä, jotta vältettäisiin toisen puolen mahdollisesta hitaudesta ja tiedonsiir­

ron viiveistä johtuvat pullonkaulat. Lisäksi normaalien transaktioita välittävien pakettien lisäksi toteutetaan "komentopaketti", johon voi sisällyttää komentoja toisille solmuille.

3.4.1 Transaktiopaketit

Normaalit välitettävät transaktiot pakataan transaktiopaketteihin. Jos jonossa on useita pieniä transaktioita, voidaan yhteen transaktiopakettiin pakata useita tran­

saktioita tehokkuuden lisäämiseksi. Transaktiot lähetetään aina kaikille sol­

muille, eli uudet joko GW- tai ydinsäikeeltä saadut transaktiot voidaan lisätä välittömästi kaikkien muiden säikeiden lähetysjonoon.

3.4.2 Komentopaketit

Komentopaketeilla voidaan ohjata muiden solmujen toimintaa tai välittää tietoa verkon tilasta. Komentopaketeilla voidaan esimerkiksi muuttaa kahden solmun välillä jaettavia tauluja tai siirtää yhteys toipumistilaan. Komentopakettien lähetys voidaan rajoittaa vain tietyille vastaanottajille tai lähimmille naapureille. Komen­

topakettien reititys voidaan rajoittaa vain sallituille vastaanottosolmuille.

3.5 Kommunikointi

Kommunikointi kahden solmun välillä tapahtuu käyttämällä normaaleja unix soketteja ja TCP/IP-protokollaa. Työssä harkittiin myös oman luotettavan siirto­

protokollan toteuttamista UDP:n päälle, koska osa TCP-protokollan toteutuksista toimii huonosti epäluotettavassa tai raskaasti kuormitetussa verkossa. Omalla protokollalla voitaisiin varmistaa maksimaalinen suorituskyky, ja sen avulla pys­

tyttäisiin saamaan tarkempaa tietoa verkon tilasta ja mahdollisesti varautumaan yhteyksien ongelmiin paremmin kuin TCP-protokollaa käyttäessä. Alustavasti kuitenkin päädyttiin käyttämään TCP-protokollaa, mutta mahdolliseen muutok­

seen myöhemmin varauduttiin eristämällä kaikki kommunikointifunktiot yhteen alimoduuliin.

Normaalitilassa soketit toimivat nonblocking-tilassa, mutta joissain erikoistapa­

uksissa, kuten yhteyttä muodostaessa ja toipumisen aikana, ne toimivat blocking tilassa. Näissä tiloissa käytetään myös synkronista tiedonsiirtomuotoa.

3.5.1 Normaalitila

Kommunikointi tapahtuu nonblocking tilassa. Vapaana olevat GW-säikeet vuoro­

tellen tarkistavat lähetysjononsa ja vastaanottosokettinsa, ja reagoivat jommasta kummasta tuleviin transaktioihin.

Lähetysjonossa olevat transaktiot tai komennot pakataan ja lähetetään vasta­

puolen GW-säikeelle. Soketista saapuva transaktio käsitellään vasta, kun se on kokonaan vastaanotettu, eli GW-säie pystyy lähettämään ja vastaanottamaan paketteja yhtäaikaa.

Saapuvan paketin käsittelyssä on seuraavat vaiheet:

1. Paketti hajotetaan yksittäisiksi transaktioiksi. Loput vaiheet suori­

tetaan kullekin transaktiolle erikseen. Komennot lähetetään aina yksitellen.

2. Tarkistetaan ID:n perusteella, onko kyseinen transaktio/komento jo käsitelty. Jos on, hylätään se. Jos ei ole, lisätään ID nähtyjen joukkoon.

3. Jos kyseessä on tälle solmulle tarkoitettu komento, joka pitää suorittaa ennen sen välittämistä eteenpäin, suoritetaan se.

4. Lisätään transaktio rengaspuskuriin ja viittaukset siihen kaikkien muiden säikeiden jonoihin. Lisätään komento kaikkiin sallittuihin jonoihin.

5. Jos kyseessä on tälle solmulle tarkoitettu komento, jota ei käsi­

telty vaiheessa 3, käsitellään se.

Koska ydinsäikeellä on samanlainen jono kuin GW-säikeilläkin, ulkopuolelta tulevan transaktion käsittely siirtyy ydinsäikeelle. Ydinsäie tyhjentää jonoaan määräajoin ja siten siirtää muista solmuista saapuneet transaktiot paikalliselle solmulle.

3.5.2 Yhteyden muodostaminen

Käynnistymisen yhteydessä hajautin avaa kuuntelevan soketin ja käynnistää sille oman säikeen. Säikeen tehtävänä on vastata kaikkiin yhteydenottopyyntöi­

hin. Aina saadessaan uuden yhteyden tämä säie luo uuden kättelijäsäikeen, jolle se antaa uuden yhteyden.

Käynnistymisen yhteydessä luodaan myös parametrointia vastaavat GW-säi­

keet, jotka alkavat aktiivisesti ottaa yhteyttä omiin kohdesolmuihinsa.

3.5.3 Kättelijä

Kättelijä lukee ja lähettää hajauttimen tunnuskoodin, protokollan versionumeron ja sovellustyypin. Tunnuskoodin ja versionumeron avulla voidaan varmistua, että vastapää osaa kommunikoida hajauttimen kanssa. Sovellustyyppi kertoo vasta- pään sovellustyypin, jonka avulla yhteyttä voidaan käsitellä sille kuuluvalla tavalla. Ominaisuutta voidaan käyttää hyväksi toteuttaessa telnet-ohjelmalla käytettävä yksinkertainen tekstipohjainen käyttöliittymä testauksen avuksi.

Jos vastapään sovellustyyppi on toinen samanlainen hajautin, molemmat puolet lähettävät toisilleen tärkeimmät parametrinsa, kuten oman solmunsa numeron.

Saatuaan toisen solmun numeron kättelijä tarkistaa, onko siihen solmuun jo ole­

massa GW-säie. Jos säiettä ei ole, luodaan se ja annetaan yhteys sille. Jos säie oli jo olemassa ja sillä ei ole yhteyttä, siirretään yhteys sinne. Muussa tapauk­

sessa yhteys suljetaan. Tämän jälkeen kättelijäsäie lopettaa toimintansa.

Yhteyttä yrittävä GW-säie yrittää ottaa yhteyttä parametrointinsa mukaiseen osoitteeseen. Yhteyden saadessaan se käyttäytyy vastaavalla tavalla kuin kätte­

lijä. Saatuaan kättelyn päätökseen, GW-säie tarkistaa, ettei saman solmun kät­

telijäsäie ole jo kytkenyt sitä johonkin. Mahdollinen ylimääräinen yhteys suljetaan.

3.5.4 Keskustelun aloitus

Yhteydenoton tässä vaiheessa molempien puolien GW-säikeet ovat samassa tilassa riippumatta siitä, miten ja kumman aloitteesta yhteys on alunperin muo­

dostunut. Aluksi säikeet neuvottelevat siitä, kumpi johtaa keskustelua. Sen jäl­

keen tarkastetaan jaetut taulut ja niiden parametrit. Jos jokin taulu puuttuu toiselta osapuolelta, se yritetään lisätä. Jos lisäys epäonnistuu tai taulun para­

metrit eroavat, kyseistä taulua ei jaeta solmujen välillä. Taulujen tarkastamisen jälkeen tarkistetaan solmujen kellojen aikaero ja varoitetaan käyttäjää, jos se on liian suuri.

Viimeiseksi tarkistetaan, mihin eri solmuihin solmut ovat olleet yhteydessä viime aikoina. Tarkastelun perusteella päätellään, millainen yhteys nyt saatiin: onko kyseessä suoran yhteyden avaaminen ennen epäsuorasti toisiinsa yhteydessä olleiden solmujen välillä, lyhyestä yhteyskatkosta toipuminen, uuden solmun liit­

tyminen verkkoon tai kahden eri verkkon osan yhdistyminen toisiinsa. Kahdessa ensimmäisessä tapauksessa voidaan siirtyä suoraan säikeen normaalitilaan, muissa tapauksissa tarvitaan jonkinlaista toipumismenettelyä.

3.5.5 Toipuminen

Toipuminen tarkoittaa pidempään verkosta erossa olleen solmun tietokannan tilan yhdistämistä muun verkon kanssa. Toipuminen aloitetaan parametroinnin salliessa automaattisesti tai käyttäjän komennosta. Järjestelmä pitää huolen siitä, että toipumista ei aloiteta molemmista solmuista ristiin, eikä eri paikoista yhtäaikaa.

Toipuminen tapahtuu taulu kerrallaan, ja siinä ei ole transaktiokäsitettä. Jos jokin taulu riippuu toisesta, voidaan parametroinnilla määrätä taulujen toipumisjärjes- tys. Jos riippuvuus on syklistä, voi tästä aiheutua lisävaatimuksia tauluja käyttä­

ville sovelluksille.

3.5.5.1 Aikaleimahajautetut taulut

Aikaleimataulujen toipuminen aloitetaan lukitsemalla toipuvan puolen koko tieto­

kanta. Seuraavaksi verrataan tauluittain molempien puolien tietokantarivien ID ja aikaleimakenttiä. Vertailu suoritetaan seuraavasti:

1. Jos tietty ID arvo puuttuu toisesta solmusta, kopioidaan rivi sinne.

2. Jos samaa ID:tä vastaavat aikaleimat eroavat, oletetaan uudempi rivi oikeaksi, ja kopioidaan sen vanhemman tilalle.

3. Jos ID:t ja aikaleimat ovat samoja, oletetaan, että rivi on jo sama molemmissa solmuissa.

Kohdassa 1 olisi mahdollista verrata rivin aikaleimaa viimeiseen tunnettuun aikaan, jolloin toiseen solmuun oli yhteys, mistä voitaisiin päätellä, onko rivi lisätty toiselle puolelle vai poistettu toiselta puolelta yhteyskatkon jälkeen. Omi­

naisuutta ei kuitenkaan haluttu tehdä, koska vanhentuneen rivin palaaminen on pienempi ongelma kuin uuden rivin virheellinen häviäminen.

Vertailun jälkeen siirretään tarvittavat rivit solmujen välillä. Verkkoon liittyvän sol­

mun tietokantarivit välitetään toipumiseen osallistuvan solmun lisäksi myös muille verkon solmuille. Prosessi toistetaan kaikille aikaleimahajautetuille tau­

luille.

Toipumisen lopuksi yhdistetään solmujen tiedot muista verkossa olevista sol­

muista, vapautetaan toipuneen solmun tietokanta ja siirretään säie normaaliti­

laan. Jos toipuneella solmulla oli muita yhteyksiä, uudelleenkäynnistetään ne kaikki, jolloin automaattisesti selvitetään, mitkä niistä kuuluivat samaan verkkoon kuin se solmu, johon liittyvä solmu juuri yhdistettiin. Mahdolliset yhteydet muihin solmuihin joutuvat toipumistilaan parametrointinsa mukaan.

3.5.5.2 Omistajahajautetut taulut

Vaatimusten perusteella omistajahajautetuiksi tauluiksi määritellään vain tauluja, joiden tiedot liittyvät vain yhteen solmuun. Näissä tapauksissa on hyväksyttävää, että omistajahajautettujen taulujen rivit eivät välttämättä ole täysin ajan tasalla muissa kuin niiden omistajasolmussa. Koska ilman aikaleimaa ei voida selvittää, mitkä rivit ovat ajan tasalla, ei toipumisessa automaattisesti käsitellä omistajaha- jautettuja tauluja. Sen sijaan kaikki omistajasolmussa tehtävät päivitykset välitty­

vät muihin solmuihin; jos riviä ei ole niissä ennestään, se luodaan. Lisäksi käyttöliittymä antaa mahdollisuuden lähettää verkkoon tiedot oman solmun riveistä, ja mahdollistaa muiden solmujen rivien kysymisen jostakin naapurisol- musta. Lisäksi on mahdollista siirtää jonkun solmun rivien omistus jollekin muulle solmulle.

3.5.5.3 Verkon fragmentoituminen

Jos verkko on jakautunut useampaan osaan ilman, että osien välissä on yhteyttä, kyseessä on verkon fragmentoituminen. Hajautin pystyy siirtämään yhden solmun toiseen verkon osaan normaaleilla toipumismenetelmillä, jolloin fragmentoituminen voidaan poistaa siirtämällä kaikki solmut samaan verkon osaan. Tämä voi kuitenkin olla hidas toimenpide, etenkin jos siirrettäviä solmuja on paljon ja verkon osien tietokannoissa on suuria eroja.

Parempi vaihtoehto olisi toteuttaa tietokantojen yhdistäminen yhdellä kertaa, mutta tämän aikaansaaminen olisi monimutkainen ja epävarma prosessi, joka voisi häiritä verkon toimintaa vielä enemmän kuin nykyinen menettely.

3.5.6 Komennot

Komennoilla hoidetaan solmujen välisessä kommunikoinnissa kaikki normaalien transaktioiden välittämisestä eroava toiminta. Komentoja tarvitaan ainakin seu- raaviin toimintoihin:

3.5.6.1 Parametroinnin muuttaminen

Komennoilla voidaan lisätä ja vähentää solmujen välillä välitettäviä tauluja ja tar­

vittaessa toivuttamaan yksittäisiä tauluja. Lisäksi voidaan käskeä vastapuolta sulkemaan yhteys väliaikaisesti tai lopullisesti.

3.5.6.2 Verkon tilan analysointi

Komennoilla on pystyttävä keräämään ja välittämään verkon tilaa koskevia tie­

toja, kuten eri solmujen välisiä etäisyyksiä ja niiden välittämiä tauluja.

3.5.6.3 Viestien välitys

Komennoilla voidaan välittää lyhyitä viestejä muiden solmujen hajauttimen loki- tai hälytysikkunaan.

3.5.6.4 Toipumiset

Komennoilla voidaan pyytää ja lähettää omistajahajautettuja tauluja muille sol­

muille tai siirtää yhteys toipumistilaan esimerkiksi jonon ylivuodon jälkeen.

Lisäksi komentoja käytetään toipumisten yhteydessä välittämään verkkoon liitty­

neen solmun tiedot verkossa jo olleille solmuille.

3.6 Säikeiden tilat

GW- ja ydinsäikeiden toiminta riippuu niiden sisäisestä tilasta. GW-säikeet teke­

vät suurimman osan tilasiirtymistään itse, mutta säikeiden tilaa voidaan myös muuttaa muista säikeistä käsin.

3.6.1 GW-säie

GW-säikeiden kaikki mahdolliset tilat, ja suurin osa tilasiirtymistä on esitetty kuvassa 3.2.

Kuvaa on yksinkertaistettu jättämällä muutama harvinaisempi tilasiirtymä väliin:

kaikkia siirtymiä tiloihin "Dying" ja "Close" ei ole piirretty. Suuri "Idle" tilaan johta­

vien siirtymien määrä johtuu siitä, että siihen palataan aina yhteyden katketessa.

Lisäksi muiden säikeiden tai käyttöliittymän tapahtumat voivat siirtää GW-säi- keen tiloihin "Dying" tai "Close" kaikista muista tiloista paitsi niistä itsestään ja

"Dead" tilasta.

Uudet säikeet käynnistyvät tilasta "Idle" paitsi, jos säie on luotu saataessa yhtey­

denotto solmusta, mihin ei ollut ennestään GW-säiettä, jolloin säie käynnistetään tilasta "Connecting". Kaikki GW-säikeet poistuvat "Dead"-tilan kautta lukuun ottamatta joitakin virhetilanteita.

Reconnect

Connecting

Waitrecover

Recovering

Normal

Halted

Close Dead

Kuva 3.2 GW-säikeen tilat ja tärkeimmät tilasiirtymät

GW-säikeiden käytös riippuu niiden tilasta seuraavasti:

• Idle: Tilaan saavutaan aina, jos yhteys vastapuoleen menetetään tai sitä ei ole vielä luotu. Tässä tilassa GW-säie yrittää aktiivisesti ottaa yhteyttä vastapuoleensa. Jos säie onnistuu muodostamaan yhteyden ja mikäli kättely onnistuu, siirtää säie itsensä "Connecting" tilaan.

• Connecting: Tähän tilaan saavutaan kättelijäsäikeen vastattua vasta­

puolen yhteydenottoon ja joko luotua uuden GW-säikeen tai siirrettyä olemassa ja "ldle"-tilassa olleen säikeen tähän tilaan. Tilaan siirrytään myös, jos säie itse saa yhteyden vastapuoleensa "ldle"-tilasta. Tässä tilassa säie tarkistaa hajautettavien taulujen määrän ja parametrit sekä toipumistarpeen. Jos toipumista ei tarvita, siirtyy säie lopuksi "Normal"

tilaan. Jos toipumista tarvitaan, siirrytään joko "Waitrecover"- tai

"Recovering"-tilaan parametroinnin mukaan.

• Waitrecover: Tässä tilassa odotetaan toipumiskäskyä joko paikalli­

selta käyttäjältä tai vastapuolelta. Ensimmäisessä tapauksessa käyttö­

liittymä siirtää säikeen "Recovering"-tilaan ja jälkimmäisessä tapauksessa ohjataan vastapuolen toipumista. Vastapuolen toipumi­

sen jälkeen siirrytään "Normal"-tilaan.

• Normal: Normaalitilassa GW-säie vastaanottaa paketteja vastapuolel­

taan ja lähettää jonossaan olevia paketteja sille.

• Recovering: Tässä tilassa pyydetään vastapuolelta toipumista. Toipu­

misen jälkeen siirrytään "Normal"-tilaan. Jos vastapuoli ei suostu toi­

vuttamaan, esimerkiksi koska se itse haluaisi toipua samaan aikaan, säie palaa "Waitrecover"-tilaan.

• Halted: GW-säie ei tee mitään - se ei edes itse pysty siirtymään pois tilasta. Tilaa käytetään pysäyttämään säie väliaikaisesti esimerkiksi selvitettäessä toipumisen jälkeisiä yhteyksiä.

• Close: Tässä tilassa suljetaan normaalitilassa ollut yhteys vastapuo­

lelle ja siirrytään "ldle"-tilaan.

• Reconnect: Tässä tilassa suljetaan tuntemattomassa tilassa ollut yhteys vastapuolelle ja siirrytään "ldle"-tilaan. Erona edelliseen tilaan on, että vastapuolelle ei pystytä kertomaan, että yhteyden sulkeminen on tarkoituksellista eikä virhetoiminto.

• Dying: Tässä tilassa suljetaan yhteys vastapuolelle. Jos yhteys oli ole­

massa, käsketään sulkea yhteys tähän solmuun lopullisesti. Yhteyden sulkemisen jälkeen siirrytään "Dead"-tilaan.

• Dead: Tämä tila päättää GW-säikeen pääohjelman suorituksen ja säie tuhotaan.

3.6.2 Ydinsäie

Ydinsäikeessä on paljon vähemmän tiloja, ja ydinsäikeen tila on samalla koko sovelluksen tila. Vaikka ydinsäikeet käyttävät samaa tietorakennetta kuin GW-

säikeet ja sitä kautta voivat saavuttaa samat tilat, on laillisiksi tiloiksi määritelty vain "Normal", "Recovering", "Halted" ja "Dying", joilla on seuraavat merkitykset:

• Normal: Normaalitilassa ydinsäie siirtää paikalliselta solmulta tulleet transaktiot GW-säikeiden lähetysjonoon ja siirtää omassa jonossaan olevat transaktiot paikalliseen tietokantaan.

• Recovering: Toipumisen yhteydessä solmun tietokantapalvelin luki­

taan tilaan, jossa se ei hyväksy muiden asiakasohjelmien kuin hajautti- men transaktioita. Lisäksi ydinsäikeen omaa jonoa ei tyhjennetä.

Käytännössä tämä tila estää kaikenlaisten normaalien transaktioiden läpimenon koko solmussa, jolloin solmun tietokantaa on mahdollista verrata ja yhdistää toisen solmun kanssa.

• Halted: Toipumista ohjaava solmu asettaa ydinsäikeensä hetkellisesti tähän tilaan tietokantojen vertailun ajaksi. Tila vastaa muuten "Recove- ring"-tilaa, mutta paikallista tietokantapalvelinta ei lukita muilta asiakas­

ohjelmilta. Paikalliselta tietokantapalvelimelta tulleita transaktioita ei käsitellä, vaan ne jätetään odottamaan ytimen sisäiseen jonoon.

• Dying: Hajautinta ollaan pysäyttämässä. Ydinsäikeen itsensä toiminta vastaa "Halted"-tilaa, mutta osa muista säikeistä osaa reagoida ytimen tilaan, ja esimerkiksi uusia GW-säikeitä ei luoda, jos ydin on "Dying"- tilassa.

4 TOTEUTUS

Tässä luvussa kerrotaan edellisessä luvussa kuvattujen toimintojen toteuttami­

nen käytännössä. Luvun toisen tason väliotsikot vastaavat edellisen luvun vas­

taavia otsikoita. Toteutusta kuvaavissa kohdissa mainitaan myös lyhyesti kyseisen kohdan tarkoitus, joten tätä lukua voidaan käyttää toteutukseen tutus­

tumiseen ilman edellisen luvun lukemista.

4.1 Perusrakenne

Kuvan 4.1 esittämän hajauttimen sisäinen modulijako noudattaa Teklan kehitys­

ympäristön modulijakoa.

parametrit

gateways

filters appjnit

main

Hajautin

Kuva 4.1 Hajautuksen hallinnan arkkitehtuuri

4.1.1 Käytetyt kirjastot

Hajauttimen toteutuksessa käytettiin projektissa jo toteutettuja kirjastoja, joihin viitataan ytimen funktioina. Näiden funktioiden avulla hoidetaan kommunikointi paikallisen solmun kanssa ja liittymäpinnat parametritiedostoihin ja käyttöliitty­

mään. Ytimen osana on myös Teklan DBfast-kirjasto, jonka avulla voidaan toteuttaa muistinvaraisia tietokantatauluja ja asettaa niihin erilaisia hakemistoja.

DBfast huolehtii tarvittaessa muistin dynaamisesta varauksesta ja tarjoaa luo­

tuun tauluun yksinkertaiset tietokantaoperaatiot (select, insert, update, delete).

4.2 MT-safe -ohjelmointi

Hajautin-palvelu on toteutettu monisäikeisenä sovelluksena, eli ohjelmaa aje­

taan näennäisesti tai moniprosessorikoneessa todellisestikin yhtä aikaa useasta eri kohdasta. Monisäikeisyys takaa suuren suorituskyvyn, koska yhden säikeen tekemä hidas operaatio ei vaikuta muihin säikeisiin. Toisaalta se aiheuttaa lisää vaatimuksia palvelun käyttämille funktioille, joiden pitää olla MT-safe, eli niitä pitää pystyä ajamaan useasta säikeestä yhtä aikaa ilman, että niiden suoritus häiriytyy. Koska ytimen funktiot eivät olleet MT-safe, ne ovat käytettävissä vain alkuperäisellä ydinsäikeellä. Kuvassa 4.2 säikeet on esitetty suorakaiteina, joilla on pyöristetyt kulmat.

3c c:

cn

o 3c

Kuva 4.2 Hajauttimen looginen rakenne

Paikallisen solmun transaktioista vastaava ydinsäie ja muihin solmuihin yhtey­

dessä olevat GW-säikeet käyttävät kaikki samanlaista tietorakennetta

(h_thread_t),

joka ylläpitää säikeen tilaa ja transaktiojonoa. Näiden säikeiden lisäksi on uusia yhteyksiä vastaanottava kuuntelija-säie ja mahdollisesti kuunte- lija-säikeen luomia kättelijä-säikeitä, jotka huolehtivat yhteyden alussa alusta­

vasta kättelystä ennenkuin on saatu selville, mille GW-säikeelle yhteys kuuluu.

4.3 Apufunktiot

Apufunktiot eristettiin omaan moduliinsa. Kuvassa 4.1 kyseinen moduli näkyy nimellä "util". Apufunktioiden testaamiseksi tehtiin lyhyt ohjelma, joka pystyy simuloimaan jono- ja rengaspuskurifunktioiden käyttöä erittäin raskaassa tilan­

teessa.

4.3.1 Säikeiden hallinta

Säikeiden hallitsemisfunktiot toteutettiin erilliseen alimoduliin. Alimoduli raken­

nettiin siten, että alla käytettävää säietoteutusta voidaan muuttaa ilman, että mihinkään muuhun moduliin tarvitsee tehdä muutoksia. Alkuperäinen toteutus tehtiin toimimaan sekä POSIX:in että Solariksen säiekirjaston kanssa. Säieali- modulin avulla voidaan luoda, tuhota ja etsiä ohjelman käyttämiä säikeitä.

Tärkeimmät säiemoduliin kuuluvat funktiot ovat:

•

h_init_threads

( ) : Funktiota kutsutaan ohjelmaa käynnistäessä.

Funktiokutsu alustaa säiemodulin tietorakenteet ja lisää sisäiseen pro- sessitauluun ydinsäikeen.

•

h list processes

(

), h_get_threads

( ) : Näiden funktioiden kut­

suilla saadaan tietoa säikeiden tilasta.

•

h_lock_process (

)

, h_unlock_process

( ) : Näiden funktioiden avulla voidaan prosesseja lukita, mikä on välttämätöntä, jos niiden tilaa halutaan muuttaa. Tämänhetkinen toteutus lukitsee koko prosessitau- lun. Koska yksittäisten prosessien lukitseminen on harvinaista ja lyhyt­

kestoista, ei katsottu aiheelliseksi toteuttaa prosessikohtaista lukitusta.

• h_init_thread ( ) :

Funktio alustaa

h_thread_t

tyyppisen raken­

teen parametrina annettavan säietyypin mukaan (TT_CORE=ydinsäie, TT_GW=GW-säie, TT_LiSTENER=kuuntelija- ja vastaajasäikeet).

•

h_start_thread

( ) : Funktio käynnistää

h_init_thread

( ) funk­

tiolla alustetun

h_thread_t

rakenteen mukaisen säikeen.

•

h_ensure_size ( )

: Funktiolla voidaan varmistaa säikeen puskuri- muistien koon riittävyys; jos tila ei riitä, funktio varaa lisää puskurimuis­

tia.

•

AddQueueList (

)

, AddQueueOthers

( ) : Näillä funktioilla voidaan lisätä haluttu transaktio säiekohtaisiin jonoihin. Ensimmäinen funktio lisää transaktion listassa olevien solmujen GW-säikeille ja jälkimmäi­

nen kaikille GW- ja ydinsäikeille paitsi siihen, miltä transaktio tuli.