Transactie (dataopslag)

Een transactie bestaat uit een aantal samenhangende acties in een database, waarbij ervoor gezorgd wordt dat deze acties ofwel allemaal plaatsvinden, ofwel geen van alle.

Uitleg

Veelal zijn er meerdere gebruikers of processen actief op een enkele database. Hierdoor kan de integriteit van de gegevens in gevaar komen. Een voorbeeld daarvan is een bankoverschrijving. Stel dat het debiteren van de rekening eerst gebeurt en daarna het crediteren van de andere rekening. Als ertussenin iets mis gaat (de verbinding wordt verbroken of de database gaat down) dan is het bedrag wel van de eerste rekening gehaald maar niet toegevoegd aan de tweede. Bij transacties zal ervoor gezorgd worden dat dit nooit kan gebeuren: ofwel gebeuren beide acties ofwel geen van beide.

Zonder een waterdichte set regels kan een database gemakkelijk verstrikt raken in een situatie als in het voorbeeld.

Een database wordt daarom geacht aan ACID te voldoen. Dat betekent dat transacties voldoen aan de eisen:

• Atomair: een transactie wordt altijd volledig uitgevoerd. Ook al bestaat een transactie uit meerdere onderdelen, na afloop van een transactie zijn of alle onderdelen uitgevoerd of geen van de onderdelen.
• Consistent: na uitvoering van een transactie is de database consistent, dat wil zeggen dat alle regels die zijn vastgelegd voor de gegevens gelden.
• Geïsoleerd: transacties worden geïsoleerd van elkaar uitgevoerd, dat wil zeggen dat transacties die tegelijkertijd worden uitgevoerd geen inzicht hebben in elkaars tussenresultaten.
• Duurzaam: na de uitvoering van een transactie zijn de gegevens duurzaam vastgelegd.

Waaruit bestaat een transactie

Elke transactie begint met een START TRANSACTION-opdracht. Dan vinden de databasehandelingen plaats. Vanuit het oogpunt van de transactie verandert de database vanaf dat moment niet meer door invloed van anderen. De benodigde tabellen worden meestal gelockt.

Als tijdens deze databasehandelingen blijkt dat de transactie niet afgemaakt kan worden (bijvoorbeeld omdat er te weinig geld op de rekening staat, of omdat de patiënt die ontslagen moet worden helemaal niet in het ziekenhuis opgenomen is) dan wordt de transactie afgebroken door middel van een rollback. Alle handelingen die sinds het begin van de transactie gedaan zijn worden niet doorgevoerd in de database of worden teruggedraaid. Het is zo dat anderen de wijzigingen in dit geval nooit te zien hebben gekregen. Als alles goed gaat volgt er een COMMIT-opdracht. Dan worden de wijzigingen definitief gemaakt, of zichtbaar voor anderen gemaakt.

Transactie-isolatieniveaus

Parallellopende transacties

Transacties worden vaak uitgevoerd wanneer een applicatie als client op een databaseserver werkt. De databaseserver bedient meestal meerdere clients tegelijk. Het kan dan zo zijn dat de transacties vanuit de vele verschillende clients met elkaar gaan beïnvloeden. In sommige gevallen betekent dat als er een waarde gewijzigd wordt, dat andere transacties die deze waarde willen wijzigen eerst helemaal teruggedraaid zouden moeten worden, om daarna opnieuw te beginnen.

De invloeden van transacties op elkaar zijn nu als volgt in te delen:

• Dirty Read - een client werkt met gegevens waarop ook andere clients transacties uitvoeren ook al zijn deze transacties niet allemaal met een COMMIT afgerond. De client werkt dus met gegevenswaarden die mogelijk via een ROLLBACK vanuit andere clients geannuleerd moeten worden. De gegevenswaarden zijn dus mogelijk dirty.
• Non-Repeatable Read - een client die in een transactie meermalen dezelfde data opvraagt, krijgt soms verschillende waarden terug. Dit ten gevolge van transacties (UPDATE en DELETE) die andere clients tegelijkertijd uitvoeren.
• Phantoms - een client die herhaaldelijk volgens een selectiecriterium gegevens opvraagt uit de database, kan geconfronteerd worden met plotseling verschijnende spookgegevens (phantoms). Dit ten gevolge van INSERT-transacties die tegelijkertijd door andere clients worden uitgevoerd en gegevens invoeren die aan het betreffende selectiecriterium voldoen.

Voor sommige SQL-transacties is het acceptabel om invloeden van andere transacties mee te krijgen. Andere transacties dienen volledig geïsoleerd te worden van andere transacties, wanneer deze tot ernstige fouten in het systeem leiden.

Transactie-isolatieniveaus bepalen nu in hoeverre de transacties die uitgevoerd worden door de ene client, de wijzigingen in de database kunnen zien door transacties van een andere client op hetzelfde moment. Er zijn vier transactie-isolatieniveaus: Read uncommitted, Read committed, Repeatable Read en Serializable.

Read uncommitted

Een transactie kan alle wijzigingen van andere transacties zien; zowel de wijzigingen die al wel zijn doorgevoerd in de database (COMMIT-commando is wel uitgevoerd), als de wijzigingen die niet zijn doorgevoerd (COMMIT-commando is nog niet uitgevoerd). Transacties die dit isolatieniveau hebben, zijn het minst geïsoleerd. Dit heeft als gevolg dat deze transacties gevoelig zijn voor alle drie de typen invloeden: Dirty Read, Non-Repeatable Reads en Phantoms.

Read committed

Een transactie kan alleen de wijzigingen zien die door andere transacties doorgevoerd zijn in de database, het COMMIT-commando is uitgevoerd. Transacties op dit isolatieniveau worden niet meer beïnvloed door Dirty Reads. Wel hebben deze transacties nog last van Non-Repeatable Reads en Phantoms.

Repeatable read

Een transactie is ongevoelig voor aanpassingen van de data (UPDATES), die de transactie heeft opgevraagd. Deze data zijn vergrendeld tegen aanpassingen, zodra een leestransactie op de data is uitgevoerd. Nieuw ingevoerde data (INSERT), zullen pas zichtbaar worden bij de eerstvolgende leestransactie. Met andere woorden, deze transacties hebben geen last meer van Dirty Reads of Non-Repeatable Reads. Ten hoogste worden deze transacties beïnvloed door Phantoms.

Serializable

Een transactie is volledig geïsoleerd van andere transacties. Een transactie die "serializable" is, heeft geen notie van wijzigingen die aangebracht zijn door andere transacties. Geen van de drie typen invloeden is daarom van toepassing op dit isolatieniveau.

Databases

databasemanagementsysteem · databasemodel · databasenormalisatie · referentiële integriteit · relationele algebra · relationele database · relationeel model