Databasteknik II: Inlämningsuppgift 5 - Transaktioner

Mål

• Att förstå principerna för hur en loggfil används i transaktionshantering, med write-ahead logging och återhämtning (recovery).
• Att kunna implementera enkel transaktionshantering med en loggfil.
• Att inse att de saker som databashanteraren gör inte är magi, utan går att skriva som ett program.
• Att lära sig lite mer om hur filhantering fungerar när man programmerar, till exempel i vilken mån ens favoritspråk buffrar utmatning till filer, och hur det kan påverka om man bygger en databashanterare i det språket.

Scenario

Tyvärr kan transaktionen avbrytas mitt i, till exempel genom en systemkrasch, ett strömavbrott eller en otålig användare. Vi måste därför hantera sådana avbrutna transaktioner.

Förberedelser

• Läs lämpligt kursmaterial med mera.
• Man behöver tillgång till en programmeringsomgivning, där man kan programmera i något vanligt programmeringsspråk, till exempel C, C++, Java eller C#. Själv har jag använt C med kompilatorn GCC under Linux, men andra alternativ går också bra, till exempel C i Visual Studio 2008.

Inledande uppgifter

1. Skriv ett program som skapar en "databas", som består av en mängd heltal som lagras på en fil. Här är ett exempel på hur ett sådant program kan se ut: createdb.c. (Man kan använda det programmet om man vill.) Det bör vara en binärfil, för med en textfil kan det bli svårt att sen skriva över enskilda tal med nya värden.
2. Kör programmet för att skapa databasen. Man kan prova med en databas som innehåller en miljon heltal, men senare kan man anpassa storleken på databasen efter hur snabb dator man har.
3. Skriv ett annat program som visar innehållet i databasen. Här är ett exempel på hur ett sådant program kan se ut: showdb.c. (Man kan använda det programmet om man vill.)
4. Provkör programmet för att titta på innehållet i databasen.
5. Skriv ett tredje program som går igenom talen i databasen, och ökar vart och ett av dem med ett. Här är ett exempel på hur ett sådant program kan se ut: incrementdb.c. (Man kan använda det programmet om man vill.)
6. Provkör ändra-programmet ett par gånger, och kontrollera med visa-programmet att ändra-programmet fungerar.
7. Kör ändra-programmet en gång till, och avbryt det mitt under körningen. Nu bör databasen vara i ett inkonsistent tillstånd, där en del av talen uppdaterats, och andra inte. Verifiera detta med visa-programmet.

Den riktiga uppgiften

1. Skriv ett nytt program som går igenom talen i databasen, och ökar vart och ett av dem med ett. men till skillnad från det tidigare ändra-programmet, ska det här programmet även anteckna alla ändringar på en loggfil, så att transaktionen kan rullas tillbaka. (Tips: Loggfilen kan vara i textformat, så har man mindre behov av att skriva ett särskilt program som visar innehållet i den.)
2. Glöm inte att skriva commit i loggfilen. Gärna start-transaction också, men om man inte skriver commit vet man inte om transaktionen är committad ("färdig") eller inte, och vid recovery vet man i så fall inte om ändringarna som transaktionen gjort i databasen ska tas bort eller skrivas på nytt.
3. Provkör det nya ändra-programmet ett par gånger, och kontrollera med visa-programmet att också det här nya ändra-programmet fungerar. Ser loggfilen riktig ut?
4. Skriv ett recovery-program, som utifrån den materialiserade databasen och loggfilen återställer databasen till ett konsistent tillstånd. Det räcker med att man kan köra en enda transaktion, och sen återställa den.
5. Verifiera att det går att avbryta ändra-programmet mitt i, och sen använda recovery-programmet för att återställa den inkonsistenta databasen.
6. Verifiera att det går att köra klart ändra-programmet, så att transaktionen committas, och att recovery-programmet sen inte tar bort transaktionens ändringar.
7. Frivilligt: Gör så att man kan köra flera transaktioner (efter varandra, inte samtidigt), och att recovery-programmet går igenom loggfilen och på lämpligt sätt hanterar alla de transaktioner som finns med.

Redovisning

Om man arbetat i en miljö som Visual Studio eller Eclipse bör man packa ihop hela projektkatalogen som en Zip-fil och skicka den som en bilaga. (Även rar- och tar-filer fungerar.) Men döp först om Zip-filen från nånting.zip till exempelvis nånting.info för att överlista överambitiösa virusfilter.

Arbeta i grupper om en eller två studenter. I undantagsfall kan man arbeta i grupper om tre, men fråga läraren först.

Det är tillåtet att samarbeta i större grupper än så, men varje grupp om 1-3 studenter måste fortfarande redovisa separat, och det måste också tydligt framgå (i rapporten eller på annat sätt) vilka som deltog i samarbetet.