Persistens avses garantera säker lagring av data oavsett datas
livslängd, som kan indelas enligt:
Persistens
•
•
•
•
•
Kan uppnås på flera sätt.
• Som ett tillägg till ett existerande språk, inte nödvändigtvis
objektorienterat,
Transienta data, uppstår vid evaluering av uttryck
Lokala variabler vid procedur- och funktionsaktivering
Lokala variabler i procedur- och funktionskroppar
Globala och/eller dynamiska variabler
Data som existerar under en programkörning
som utgör de traditionella persistensklasserna och
• genom användning av ett specialdedicerat
databasprogrammeringsspråk eller
• genom utvidgning av traditionella databaser, som redan beskrivits.
• Data som varar under ett programs livstid
• Data som överlever flera programversioner
• Data som överlever alla programversioner
som är de nya persitensklasserna, där datas livslängd inte längre avgörs av den
enskilda programkörningen.
2D1470
Bild 1
2D1470
Krav och principer för persistens
Bild 2
Önskvärt att
Ortogonal persistens = Alla data, oberoende av typ, skall kunna vara
persistenta, oavsett perspektiv på livslängd.
• hanteringstiden för kortlivade värden inte påverkas genom
införande av långlivade värden,
Persistensoberoende = Program skall exekvera på samma sätt
oberoende av livslängdsperspektivet på de data, som programmet
opererar på.
• tiden för exekvering av program inte ökar p g a införande av
långlivade värden.
Mekanismerna för identifikation av datas livslängd skall ingå i
språkets semantik.
2D1470
Bild 3
2D1470
Bild 4
Vinster
g
pplin
as-ko
• Ökad produktivitet genom enklare semantik.
datab
applikation
• Frånvaron av persistens leder oftast till ”ad hoc”-lösningar för att
täcka behovet av långlivade värden och transaktionshantering.
applikation
• Typkontroll kan ske globalt i stället för lokalt i programmen.
databas
konce
gränssnitt 3gl/världen
gränssnitt 3gl/världen
ptuell
mode
ll
världen
världen
• Referensintegritet kan enklare upprätthållas genom den direkta
kopplingen mellan data i och utanför programmen.
• Konceptuell förenkling genom en avbildning i stället för tre.
2D1470
Bild 5
2D1470
Införande av persistenta värden
Förenklad programkonstruktion erhålls genom att
•
•
•
•
•
Bild 6
förutsätter tillgång till permanent objektminne (DB, PS) som skall
Alla värden är första klassens värden
Inkrementell laddning av data (inklusive programdelar)
• acceptera och tillåta återvinning av alla typer av värden
• tillhandahålla transaktionshantering för kontroll av parallella processer och
återhämtning
• tillhandahålla mekanismer för säkerhets- och integritetskontroll
• tillhandahålla mekanismer för typkontroll
• vara självorganiserande
Ovanstående ger även möjlighet till programlänkning
Typkontroll av sådan länkning sker automatiskt
Möjlighet till inkrementell programkonstruktion och inkrementellt
programunderhåll.
• bibliotek av program, programdelar och data kan skapas
2D1470
Bild 7
2D1470
Bild 8
Införande av persistenta värden förutsätter . . .
Införande av persistenta värden förutsätter . . .
metoder för att identifiera värdens livslängd och
inkrementell bindningsmekanism
• automatiskt kunna lagra långlivade väden
• upprätthålla den del av systemets semantik som avser samtidig åtkomst av
värden.
• för att kunna kombinera existerande data med nya
◆ nya program skall kunna köras mot redan lagrade värden
◆ gamla program skall klara att köra mot nya värden
◆ skapande av programbibliotek
mekanismer för identifikation av enstaka objekt för att
metoder för typkontroll
• lagring av långlivade värden skall vara stabil
• kunna upprätthålla den del av systemets semantik som avser samtidig åtkomst av
värden
• kunna upprätthålla referensintegritet.
2D1470
Bild 9
Vanliga mekanismer i persistenssystem
2D1470
Bild 10
• flera nivåer hos lagringsmediet
• livslängdsbestämning genom åtkomst
◆ identifiering av roten till datastrukturer för permanent lagring
(strukturen överlagras på andra datastrukturer)
◆ dessa rötter skall kunna namnges i programmen
◆ det skall vara tillåtet att göra värden långlivade genom att inkorporera dem i
redan befintiliga sådana strukturer
◆ det skall gå att göra värden transienta genom att exkludera dem från en
persistent struktur
◆ de värden som systemet vid en given tidpunkt skall spara är alla värden som är
åtkomliga från alla persistenta rötter. Detta eliminerar risken för misstämmande
referenser (tappade värden)
◆ ger inkrementell undanlagring av värden och metadata
2D1470
• införande av persistens får inte innebära en försvagning av typsystemet
Bild 11
◆ De flesta systemen har minst två nivåer
en aktiv och en stabil del
◆ Det kan finnas fler nivåer av säkerhets och/eller effektivitetsskäl
◆ För användarna skall omgivningen uppfattas som homogen
2D1470
Bild 12
Persistent objektminne
alla data som kan nås från en eller flera rötter är persistenta.
Kräver att alla data organiseras som objekt och att dessa data innehåller
referenser till andra objekt.
Höljet till varje rot utgör en databas i PS-algol.
Alla objekt som kan nås från roten blir persistenta då commit exekveras.
Återvinning av data sker då de refereras.
Identifikation av persistenta objekt
I princip 3 olika sätt:
Alla data är persistenta.
Den enklaste metoden är att alla värden spars då programmet terminerar.
När man behöver dessa värden läses hela arean in till programmet.
Metoden känd som ”core dumping”.
Nackdelar: ändligt utrymme, arean hanteras som en enhet.
Transaktioner
Behövs för att garantera att gemensamma data uppdateras på rätt sätt.
endast explicit markerade data är persistenta.
All förflyttning mellan programvariabler och det persistenta minnet är explicita.
Persistenta variabler deklareras som ”dynamic”, ”persistent”, . . .
Dessa spars genom ”export” och hämtas med ”import”.
De värden som exporteras blir persistenta då ”checkpoint” utföres.
Namngivning av objekt
Objekt måste kunna identifieras.
Objektens komplexitet kan variera från enstaka ord till mycket komplexa strukturer.
Nackdelar:
man arbetar med kopior av persistenta data. Egentligen bara filhantering.
2D1470
Bild 13
Hantering av data i en hierarki av lagringsmedia
Olika lagringsmedia såsom tape, disk, primärminne, . . . används i datorsystem.
I denna hierarki lagras långlivade data på tape och disk medan kortlivade data lagras
i primärminnet.
Eftersom persistensabstraktionen tillåter programspråksfaciliteterna att användas på
alla data måste dessa hanteras som om de låg i primärminnet.
Detta kan uppnås genom att överföringen mellan primär- och sekundärminnet
automatiseras.
Coredumping kan automatiseras på ett enkelt sätt medan andra tekniker kräver mer
sofistikerade automatiseringsmekanismer.
2D1470
Bild 14
I oop ser programmeraren ett oändligt minne, detta måste då också
vara fallet då persistens används.
Objekt kan lagras på en heap och varje sådant objekt kan då nås från
en distinkt rot. Tolkningen av objektet sker i högre nivåer.
Lägre nivåer hanteras med checkpoints.
Objekten skapas, hanteras och förstörs med anrop av metoder i
heapen.
Skydd av data från felaktig användning
alla mekanismer kända från vanliga dbms kan användas inklusive typkontroll i
språket.
2D1470
Bild 15
2D1470
Bild 16
Skräpsamling
Distribution
Parallellitet
måste göras i både programmets heap och på sekundärminnet.
Transaktioner
• Skräpsamling i heapen:
Abstrakt maskin
◆ Alla objekt som inte kan nås från roten till det persistenta minnet skall tas bort.
◆ Alla objekt som skall kastas finns i heapen.
Heap med persistenta objekt
Skuggsidehanterat virtuellt minne
• Skräpsamling i det persistenta minnet:
Ickeflyktigt minne
◆ Alla objekt som inte kan nås från roten till det persistenta minnet skall tas bort.
Mjukvarugränssnitt mot den fysiska maskinen
Fysisk maskin
2D1470
Bild 17
Skuggsida
2D1470
Bild 18
Antag att en transaktion utför ”write(X)” där X är ett objekt lagrat på
sida j i databsaen. Exekveringen kommer då att fortlöpa enligt:
för hantering av commit och rollback
Databasen partitioneras i ett antal sidor numrerade 1..n.
Med hjälp av en sidtabell kan en sida hittas även om de inte ligger i
någon speciell ordning på disken.
Huvudiden med skuggsidtekniken är att upprätthålla två sidtabeller.
Då en transaktion startar är de två tabellerna, ”current” och ”shadow”,
lika.
1. Om den j :te sidan inte redan är i primärminnet så läses den in
2. Om det är den första operationen på sidan j som utförs av transaktionen så
modifieras sidtabellen enligt
(a) hitta en oanvänd sida på disken
(b) ta bort sidan från den fria arean
(c) modifiera sidtabellen så att sidan j nu är den som hittades i 2a
3. Tilldela X det nya värdet. Om transaktionen gör commit så kopiera current till
disken och sedan till shadow. Vid rollback kopiera shadow till current. Vid
återhämtning läs shadow från disken.
Fördelar: Snabbare, mindre overhead
Shadow ändras aldrig under transaktionen.
Nackdelar: Fragmentering av minnet, skräpsamling (”gamla” sidor
måste återvinnas)
Current kan ändras vid en läsning eller skrivning av databasobjekt.
2D1470
Bild 19
2D1470
Bild 20
Persistenta språk
O++:
(Språk för persistent programmering)
ett subjektivt urval
•
•
Objektorienterat, bygger på C++
Alla värden första klassens värden
PS-Algol:
Pjama:
•
•
•
•
•
•
Ortogonal persistens
Både statisk och dynamisk bindning
Procedurer är första klassens värden
Reflektion
Objektorienterat, utvidgning till Java
Ortogonal persistens
Napier:
•
•
•
•
Bygger på PS-Algol (har alla dess egenskaper) +
Polymorfi och abstrakta datatyper
Omgivningar är första klassens värden
Ny datatyp any
2D1470
Bild 21
2D1470
PS-Algol
Bild 22
PS-Algol-persistens
Experimentsystem från S:t Andrew’s, Glasgow och Edinburgh Universitet
Ett programspråk för ”persistent programming”, som
•
•
•
•
•
•
•
•
•
har ortogonal persistens,
är typkomplett,
har högre ordningens procedurer
har avbrottshantering
har reflektion (= kompilatorn kan anropas inifrån program för att inkrementellt
kompilera ny kod och länka in objektmodulen under pågående körning)
har starkt typad persistent lagring
har transaktionshantering,
har parallellitet
har har visat sig användbart för att skriva databashanteringssystem och
databasapplikationer
2D1470
Bild 23
Eftersom språket har datatypkomplett persistens kan värden av alla
typer deklareras att ha vilken livstid som helst.
Då språket har fullständig persistenstransparans så finns ingen
skillnad i notation för att operera på data av olika livslängd.
2D1470
Bild 24
Idéerna
Tillvägagångssätt i PS-Algol
Det finns ett godtyckligt antal av användaren skapade rotreferenser för persistens,
kallade databaser.
(varför PS-Algol och inte ett helt nytt språk?)
Databaser
Att gå från ett känt programmeringsspråk till en utvidgad variant (med
persistens) bör inte vara en stor omställning
(varför en så enkel/liten utvidgning?)
• Namnges av användaren.
• Skyddas av ett lösenord – grövsta sortens skydd (hela databaser, inte enstaka
värden.
• Är den minsta enheten för samtidighet (kan inte låsa enskilda värden).
Databaser kan
Persistenta varianter av ett språk bör vara rimligt enkelt att
åstadkomma.
• Öppnas i läs eller läs/skriv-mod
• Skapas
• Delta i transaktioner
Praktiskt sett måste man tillgodose en liten mängd extra krav.
Lagrade värden (och deras innehåll)
• bevaras om de kan nås från en databas
• uppdateras vid commit
2D1470
Bild 25
a
b
c
Bild 26
Första klassens värden är värden som kan lagras i en datastruktur,
skapas av ett uttryck, returneras av en funktion, sändas till procedurer
och funktioner som aktuella parametrar och vara en variabels värde.
Kombinationen av lagringssemantik, första klassens funktioner och
procedurer och persistens ger
Alla värden som nås från en eller flera ”rötter” överlever till senare.
För att göra ett värde långlivat måste programmeraren se till att det kan
nås från en databasrot.
För att åter göra värdet transient elimineras alla vägar från
databasrötter till värdet.
2D1470
2D1470
Bild 27
•
•
•
•
•
•
•
•
•
Programkonstruktionsmetoder
Separatkompilering
Programbibliotek
Automatrisk inkrementell laddning
Skyddsmekanismer
Inkapsling
Abstrakta datatyper
”Databaser med inbyggt betende”
Kombinationer av data och program i databaserna
2D1470
Bild 28
Det som motsvarar klasser kallas ”structure”.
Man kan deklarera variabler av typen pntr, som kan referera till alla
instanser av varje sådan structure-”klass”.
pntr är en infinit unionstyp vars domän är nil + alla instanser av
strukturer.
pntr är starkt typad, men samtidigt dynamiskt typad på samma sätt
som pekare i Pascal.
Reflektion är en möjlighet för ett system att understödja sin egen
utveckling.
Används för att manipulera och generera källkod, kompilera källkod
och manipulera eller använda den resulterande objektkoden.
2D1470
Bild 29
Reflektion finns i PS-Algol genom att varje program/under-program
kan anropa kompilatorn.
Reflektion gör att det går att skapa kod som beror av typen på de
värden som koden arbetar på.
Reflektion ger också en garanti avseende typintegritet i systemet
genom att alla program verifieras av kompilatorn.
Det ger viss begränsad form av polymorfi och genericitet.
Ger också möjlighet till browsing, datamodelleringsmöjligheter,
schemaeditering frågespråksfaciliteter samt möjlighet till
implementation av andra programmeringsspråk.
2D1470
Viktigt i databassammanhang är stödet för hantering av stora mängder
data, vilket finns i PS-Algol avseende vektorer, strängar och bilder.
Napier88
•
•
•
•
•
•
•
•
•
•
•
2D1470
Bild 31
Bild 30
bygger på PS-Algol, med följande skillnader:
En databasrot.
Databasen innehåller då den skapats alla fördefinierade procedurer/funktioner.
Strukturekvivalens, så att flera program kan använda samma data, utan att behöva
använda samma typdeklaration.
Ett rikare typsystem (parametriska typer, polymorfi)
Varje användare av databasen kan utöka den
Då ett program har avslutats kommer automatiskt varje objekt som går att nå från
”den persistenta roten” att överleva
typen pntr i PS-Algol ersätts av typen ”any”
för att öka kraftfullheten hos typkonstruktorer använder Napier en enkel
typalgebra
Typalgebran evalueras innan programmet exekverar
Rekursiva typer för beskrivning av repetitiva datastrukturer
Parametriserade typer ger mindre komplexa program
2D1470
Bild 32
Typkontrollen är statisk om inte användaren begär dynamisk kontroll.
O++
Ingen automatisk typkonvertering sker i systemet.
Bygger på C++, med tillägg för att hantera persistens.
Egenhet p g a att omgivningar kan sparas så att flera program kan köra
i samma omgivning (L-värdesbindningar (L=location)).
Man kan skapa långlivade värden och versioner av alla typer av värden.
Man kan binda till plats snarare än till ett värde, så att flera program
kan få samtidig uppdatering av ett värde om ett av programmen
uppdaterar värdet.
Ger samtidighetsproblem.
Tillägg för att iterera över alla objekt av viss typ och för att hantera
trasaktioner och frågor till systemet (queries).
Endast objekt kan vara persistenta - inte objektklasser (typer).
Multipelt arv används för att referera till objekt i databasen.
C++ har utökats med det reserverade ordet ”persistent”.
2D1470
Bild 33
2D1470
Deklareras med t ex
enkelt att göra ett transient objekt persistent
persistent item *pip;
pip = ip;
skapas med
innehåller mängder:
pip = pnew item(initialvärden);
persistent item *itemSet [[maxNoOfItems]];
kastas med
har iteratorer för mängd- och clustergenomgång
pdelete pip;
for (pip in item) suchthat (pip->price() > 1000)
printf("%s\n", (char *) pip -> name());
Bild 34
enkelt att göra ett persistent objekt transient
item *ip;
ip = pip;
2D1470
Bild 35
2D1470
Bild 36
Detta kallas aktivering och innebär att objektet kopieras till ODEs
primärminnesbank.
ODE
Objekthanteraren ODE (Object Database Environment) ser den globala
databasen som en mängd lokala databaser, som i sin tur består av
”clusters”.
Inversen — att kopiera tillbaka ett kanske ändrat objekt kallas
passivisering eller synkronisering.
Varje lokal databas är en ”cluster group”.
ODE kontrollerar två minnesbanker en på sekundärminne, som
innehåller passiva objekt och en i primärminnet, som innehåller aktiva
objekt.
Då ett program startar ligger alla dess persistenta objekt i det passiva
minnet.
För att ett objekt skall kunna svara på ett metodanrop måste det
aktiveras, men behöver inte kopieras till programmet.
2D1470
Bild 37
O++kompilatorn
översätter till C++kod, som sedan kompileras vidare till maskinspråk,
efter att O++kompilatorn lagt till sin egen rotklass som extra
superklass.
2D1470
Bild 38
Det finns stöd för versionshantering, som är en objektegenskap, inte
en klassegenskap, så både versionsbundna och icke versionsbundna
objekt kan skapas.
Det finns dessutom ett deklarativt frågespråk, CQL, för att ställa frågor.
Multipelt arv är alltså nödvändigt för att ODE överhuvud taget skall
fungera.
”Overloading” har också visat sig värdefullt.
Man har undvikit generiska klasser och procedurer.
ODE har också ett grafiskt gränssnitt med en browser för full kontroll
av och fullt stöd för ad hoc-frågor.
2D1470
Bild 39
2D1470
Bild 40
