Teknologi Flashcards
Findes der tilfælde hvor det kan være nødvendigt at lave en explicit transaktion på en enkelt SQL query?
Ja, hvis operationen udføres på en delt ressource og tilgangen til samtidighedskontrollen er pessimistisk. (Låsning af data i databasen)
Hvilke to strategier for samtidighedskontrol arbejder vi med?
Pessimistisk og optimistisk samtidighedskontrol.
Hvad kendetegner pessimistisk samtidighedskontrol?
Låsning af dataen i databasen. Påvirker performance negativt. Introducerer deadlocks.
Hvilke to slags låsninger bruges der i den pessimistiske samtidighedskontrol? Og hvad kendetegner dem?
Exclusive lock (write): låser den data der arbejdes på og fratager al slags adgang fra øvrige tråde eller transaktioner.
Shared lock (read): låser den data der arbejdes på, men tillader andre tråde eller transaktioner at læse på dataen. Introducerer læsefænomener der kan forårsage inkonsistent data.
Hvilke forskellige læse fænomener introducerer brugen af en shared lock til håndtering af samtidighedsproblematikker? Nævn dem blot med navn.
- Dirty reads
- Non-repeatable reads
- Phantom reads
Hvornår opstår læse fænomenet “dirty reads” i forbindelse med brugen af shared lock til samtidighedskontrol?
Eks. Når en transaktion opdaterer data, som en anden transaktion læser på, hvorefter første transaktion laver rollback. På den måde har anden transaktion læst en forkert værdi.
Hvornår opstår læse fænomenet “non-repeatable reads” i forbindelse med brugen af shared lock til samtidighedskontrol?
Eks. Når en transaktion læser på data to gange, og en anden transaktion opdaterer dataen mellem de to læsninger. På den måde får første transaktion ikke det samme resultat begge gange.
Hvornår opstår læse fænomenet “phantom reads” i forbindelse med brugen af shared lock til samtidighedskontrol?
Eks. Når en transaktion læser på data to gange, og en anden transaktion opdaterer dataen mellem de to læsninger. På den måde får første transaktion enten flere eller færre rækker anden gang til sammenligning med første gang.
Hvordan undgår man at de forskellige læse fænomener forårsager inkonsistent data?
Ved at definere isolationsniveauet på den connection til databasen som transaktionerne eller trådene benytter - altså med andre ord defineres det hvordan, og hvor “strengt”, dataen låses.
Hvilke forskellige isolationsniveauer findes der til låsning af data i en database?
- Serializable: Låser hele datasættet
- Repeatable read: Låser en række
- Read comitted: Låser et enkelt felt
- Read uncomitted: Låser intet
Hvad viser billedet?
De forskellige isolationsniveauer, og hvilke læse fænomener de hver beskytter imod.
Hvad kendetegner optimistisk samtidighedskontrol?
Der benyttes ikke låsning af dataen i databasen. Samtidighedskontrollen håndteres med logik i applikationskoden. Bedre performance - specielt hvis der er mange brugere af systemet.
Hvordan løser den optimistiske tilgang samtidighedsproblematikker?
Ved versionsstyring - gøres nemmest ved at påføre en Timestamp attribut i databasen der automatisk opdateres hver gang der foretages ændringer i en række. På den måde kan det tjekkes hvorvidt brugerens version af dataen er den rigtige.
Hvad er en deadlock? Og hvilke 4 guidelines er der til at undgå deadlocks i database transaktioner?
Deadlock: Når to transaktioner står i en uendelig løkke og venter på hinanden.
Guidelines:
1. Hvis read operationer ikke er nødvendige i transaktionen, flyttes de udenfor.
2. Altid tilgå tabeller i samme rækkefølge
3. Undgå at bruge SELECT* - for at undgå at låse mere end der er behov for
4. Brug optimistisk samtidighedskontrol hvis det er muligt
Hvornår benytter man som udgangspunkt altid en pessimistisk tilgang til samtidighedskontrol?
Når en transaktion indeholder mere end én SQL query - og specielt hvis én eller flere opdaterer eller sletter.
