Tranzakció (transaction): a fogalom definíciója és jelentése a számítástechnikában

A tranzakció fogalma a számítástechnikában alapvető fontosságú, különösen az adatbázis-kezelés és az elosztott rendszerek világában. Egy olyan műveleti egységet jelöl, amely egy vagy több adatbázis-műveletet foglal magában, és ezeket egyetlen, oszthatatlan logikai egészként kezeli.

Ez az oszthatatlanság biztosítja, hogy a rendszer vagy az összes műveletet végrehajtja sikeresen, vagy egyetlenegy sem kerül végrehajtásra. Ez a „minden vagy semmi” elv garantálja az adatok integritását és konzisztenciáját, még hibák vagy rendszerösszeomlások esetén is.

A tranzakciók lehetővé teszik a komplex üzleti folyamatok megbízható kezelését. Gondoljunk például egy banki átutalásra, ahol a küldő számlájáról levonják az összeget, majd a fogadó számlájára jóváírják azt. Ez a két művelet csak akkor tekinthető sikeresnek, ha mindkettő megtörténik.

Ha az egyik sikertelen, például a jóváírás valamilyen okból meghiúsul, a teljes tranzakciót vissza kell vonni. Ez azt jelenti, hogy a levonásnak is érvénytelenné kell válnia, visszaállítva a rendszer állapotát a tranzakció előtti, konzisztens állapotba. Ez a mechanizmus elengedhetetlen a modern informatikai rendszerek megbízható működéséhez.

A tranzakció fogalmának alapvető definíciója a számítástechnikában

A számítástechnikában a tranzakció egy olyan logikai műveletegyüttes, amely valamilyen adatállapot-változást idéz elő. Lényege, hogy a benne foglalt összes részfeladatnak sikeresen le kell futnia ahhoz, hogy a tranzakció egésze sikeresnek minősüljön. Ha bármelyik részfeladat hibát jelez, az egész tranzakciót vissza kell gördíteni, vagyis az összes addigi változást visszavonni.

Ez a megközelítés kulcsfontosságú az adatbázis-kezelő rendszerek (DBMS) és más kritikus alkalmazások esetében, ahol az adatok integritása és konzisztenciája elsődleges szempont. Egy tranzakció célja, hogy a rendszer egyik konzisztens állapotból egy másik konzisztens állapotba kerüljön, még hibák vagy párhuzamos hozzáférések esetén is.

A tranzakciók megjelenése az 1970-es években forradalmasította az adatkezelést. Korábban a programozóknak manuálisan kellett kezelniük a hibákból eredő adatvesztést vagy inkonzisztenciát, ami rendkívül bonyolulttá és hibalehetőségekkel telivé tette a rendszerek fejlesztését. A tranzakciós modellek bevezetésével ez a teher jelentősen csökkent.

A fogalom nem korlátozódik kizárólag adatbázisokra. Megtalálható operációs rendszerek fájlrendszereiben, üzenetsorokban, elosztott rendszerekben és napjainkban már a blokklánc technológiában is, bár eltérő implementációval és garanciákkal. Mindig az a cél, hogy egy sor műveletet egyetlen, megbízható egészként kezeljünk.

Az ACID tulajdonságok – a tranzakciók sarokkövei

A tranzakciók megbízhatóságát és integritását garantáló alapelveket az ACID tulajdonságok összessége írja le. Ez egy mozaikszó, amely az Atomicity (atomicitás), Consistency (konzisztencia), Isolation (izoláció) és Durability (tartósság) szavak kezdőbetűiből áll. Ezek a tulajdonságok együttesen biztosítják, hogy a tranzakciók megbízhatóan működjenek kritikus rendszerekben.

Ezek az elvek először az 1980-as évek elején, Jim Gray és Andreas Reuter munkássága révén váltak széles körben ismertté, és azóta is a relációs adatbázis-kezelő rendszerek (RDBMS) alappilléreinek számítanak. Bár az elosztott rendszerek és a NoSQL adatbázisok megjelenésével némileg lazultak ezek a szigorú követelmények bizonyos esetekben, az ACID továbbra is a „gold standard” a tranzakciós megbízhatóság szempontjából.

Az ACID tulajdonságok megértése elengedhetetlen mindenki számára, aki adatbázisokkal vagy elosztott rendszerekkel foglalkozik. Ezek határozzák meg, hogy egy rendszer mennyire képes megbízhatóan kezelni az adatok változását, párhuzamos hozzáférések és rendszerhibák esetén is. A következő alfejezetekben részletesen vizsgáljuk meg mindegyik tulajdonságot külön-külön.

Az atomicitás részletes vizsgálata

Az atomicitás az ACID tulajdonságok első betűje, és talán a leginkább alapvető. Azt jelenti, hogy egy tranzakcióban szereplő összes műveletet egyetlen, oszthatatlan egységként kell kezelni. Vagy mindegyik művelet sikeresen végrehajtódik, vagy egyik sem. Nincs köztes állapot.

Ez a „minden vagy semmi” elv kulcsfontosságú az adatbázisok integritásának fenntartásában. Ha egy tranzakció során bármilyen hiba lép fel – legyen az hardverhiba, szoftverhiba, hálózati probléma vagy felhasználói beavatkozás –, az összes addig végrehajtott műveletet vissza kell vonni, és a rendszer állapotát vissza kell állítani a tranzakció előtti állapotba.

Például egy online vásárlás során, ha egy felhasználó termékeket tesz a kosarába, majd fizetni próbál, az fizetési tranzakció több lépésből állhat: a termékek készletének csökkentése, a felhasználó bankszámlájának terhelése, a rendelés státuszának frissítése. Ha a bankszámla terhelése sikertelen, az atomicitás elve szerint a készletcsökkentést és a rendelés státuszának frissítését is vissza kell vonni. A tranzakció meghiúsul, és a rendszer úgy viselkedik, mintha soha nem is próbálkozott volna a fizetéssel.

Az atomicitás megvalósításához a legtöbb adatbázis-kezelő rendszer tranzakciós naplót (transaction log) használ, más néven write-ahead logot (WAL). Ez a napló rögzíti az összes változást, mielőtt azok véglegesen rögzítésre kerülnének az adatbázisban. Hiba esetén a napló segítségével lehet visszaállítani az eredeti állapotot, vagy befejezni a félbehagyott, de már naplózott műveleteket.

A konzisztencia elve és megvalósítása

A konzisztencia az ACID második betűje, és azt jelenti, hogy egy sikeresen végrehajtott tranzakció a rendszert egyik érvényes állapotból egy másik érvényes állapotba viszi. Ez azt jelenti, hogy a tranzakció befejeztével az adatbázis minden előre definiált szabályának, korlátozásának és integritási kényszerének továbbra is meg kell felelnie.

Ezek a szabályok magukban foglalhatják az egyedi kulcsok (primary keys) érvényességét, az idegen kulcsok (foreign keys) hivatkozási integritását, a NOT NULL kényszereket, a CHECK feltételeket és az adatbázis-specifikus triggereket. A konzisztencia tehát azt garantálja, hogy a tranzakció soha nem hagyja az adatbázist érvénytelen vagy ellentmondásos állapotban.

Például, ha egy adatbázisban van egy szabály, miszerint egy bankszámla egyenlege soha nem lehet negatív, akkor egy tranzakciónak, amely pénzt von le egy számláról, biztosítania kell, hogy az egyenleg ne süllyedjen nulla alá. Ha ez megtörténne, a tranzakciót vissza kell vonni, vagyis az atomicitás lép életbe a konzisztencia fenntartása érdekében.

A konzisztencia nem csupán a tranzakciók belső logikájától függ, hanem az adatbázis sémájától és az azon definiált integritási szabályoktól is. A fejlesztő feladata, hogy olyan tranzakciókat tervezzen, amelyek tiszteletben tartják ezeket a szabályokat, és az adatbázis-kezelő rendszer feladata, hogy érvényesítse azokat a tranzakciók végrehajtása során.

A konzisztencia biztosítja, hogy az adatbázis mindig egy érvényes állapotban maradjon, függetlenül a tranzakciók bonyolultságától vagy a fellépő hibáktól.

Az izoláció mint a párhuzamosság garanciája

Az izoláció az ACID harmadik betűje, és azt a tulajdonságot írja le, hogy a párhuzamosan futó tranzakciók egymástól elszigetelten működnek. Ez azt jelenti, hogy minden egyes tranzakció úgy hajtódik végre, mintha az lenne az egyetlen tranzakció, amely a rendszeren fut. A többi párhuzamosan futó tranzakció hatásai láthatatlanok maradnak a többi számára, amíg a tranzakció nem fejeződik be.

Ez a tulajdonság létfontosságú a több felhasználót vagy több alkalmazást kiszolgáló rendszerekben, ahol számos tranzakció futhat egyidejűleg. Az izoláció megakadályozza az úgynevezett párhuzamossági problémákat, mint például a piszkos olvasás (dirty read), a nem ismételhető olvasás (non-repeatable read) és a fantom olvasás (phantom read).

Például, ha két felhasználó egyszerre próbálja megvenni ugyanazt a terméket, az izoláció biztosítja, hogy az egyik tranzakció ne lássa a másik tranzakció részleges, még nem véglegesített változásait. Csak az egyik tranzakció fogja sikeresen lefoglalni a terméket, és a másik tranzakciót vissza kell utasítani, vagy várnia kell, amíg az első befejeződik.

Az izoláció megvalósítására az adatbázis-kezelők különböző zárolási mechanizmusokat (locking) és többverziós párhuzamosság-vezérlést (MVCC – Multi-Version Concurrency Control) alkalmaznak. Ezek a technikák biztosítják, hogy az adatokhoz való hozzáférés szabályozott legyen, és a tranzakciók ne zavarják egymást. Az izoláció mértéke azonban konfigurálható, és különböző izolációs szintek léteznek, amelyek eltérő kompromisszumokat kínálnak a párhuzamosság és a konzisztencia között.

A tartósság biztosítása – adatok a végtelenben

A tartósság (durability) az ACID utolsó betűje, és azt jelenti, hogy amint egy tranzakciót sikeresen véglegesítettek (commit), annak változásai tartósan fennmaradnak a rendszerben, még áramkimaradás, rendszerösszeomlás vagy egyéb hardverhiba esetén is. A véglegesített adatok soha nem veszhetnek el.

Ez a tulajdonság biztosítja a felhasználók számára, hogy ha egyszer egy műveletet megerősítettek, annak eredménye garantáltan megmarad. Egy banki átutalás után a felhasználó jogosan várja el, hogy a pénz ténylegesen elhagyta a számláját, és megérkezett a címzetthez, függetlenül attól, hogy mi történik a szerverrel közvetlenül a tranzakció után.

A tartósság megvalósításának alapja a nem-volatilis tárolás (non-volatile storage), mint például a merevlemezek vagy SSD-k, valamint a tranzakciós naplózás. Mielőtt egy tranzakciót „commit”-nak nyilvánítanának, az összes változást tartalmazó naplóbejegyzést fizikailag rögzíteni kell a nem-volatilis tárolón. Ez a write-ahead log (WAL) technika biztosítja, hogy egy rendszerösszeomlás után a napló segítségével az adatbázis helyreállítható legyen a legutolsó konzisztens állapotba, és a véglegesített tranzakciók adatai ne vesszenek el.

A tartósság nem csupán az adatbázis szintjén fontos, hanem az egész infrastruktúra szempontjából is. Redundáns tárolók, RAID konfigurációk, adatbázis replikáció és biztonsági mentések mind hozzájárulnak a tartósság magasabb fokú biztosításához. A tartósság az a tulajdonság, amely a felhasználói bizalom alapját képezi.

Tranzakciók a relációs adatbázis-kezelő rendszerekben

A relációs adatbázis-kezelő rendszerek (RDBMS) a tranzakciókezelés prototípusát jelentik. Ezek a rendszerek az 1970-es évektől kezdve épültek ki az ACID tulajdonságok szigorú betartására, hogy garantálják az adatok integritását és konzisztenciáját még komplex, párhuzamosan futó műveletek esetén is. Az SQL (Structured Query Language) a szabványos nyelv, amellyel a tranzakciókat kezelni lehet ezen rendszerekben.

Az RDBMS-ekben egy tranzakció általában egy BEGIN TRANSACTION vagy START TRANSACTION paranccsal kezdődik, és egy COMMIT vagy ROLLBACK paranccsal fejeződik be. A COMMIT véglegesíti a tranzakcióban végrehajtott összes változást, míg a ROLLBACK visszavonja azokat, visszaállítva az adatbázist a tranzakció előtti állapotba.

A tranzakciók kulcsszerepet játszanak az üzleti alkalmazásokban, ahol az adatok pontossága elengedhetetlen. Például egy könyvelési rendszerben minden egyes főkönyvi bejegyzés, egy e-commerce platformon minden egyes rendelés feldolgozása, vagy egy egészségügyi rendszerben a páciensek adatainak frissítése egy-egy tranzakció keretében történik.

Az RDBMS-ekben a tranzakciókezelés magában foglalja a párhuzamosság-vezérlési mechanizmusokat (zárolás, MVCC), a tranzakciós naplózást a helyreállításhoz, valamint az izolációs szintek beállításának lehetőségét, amelyekkel a fejlesztők optimalizálhatják a rendszer teljesítményét és a konzisztencia igényeit.

SQL tranzakciókezelési parancsok és működésük

Az SQL szabványos parancsokat biztosít a tranzakciók explicit kezelésére. Ezek a parancsok alapvetőek minden olyan alkalmazás fejlesztéséhez, amely megbízható adatkezelést igényel relációs adatbázisokban.

A legfontosabb parancsok a következők:

• START TRANSACTION vagy BEGIN TRANSACTION: Ez a parancs jelöli egy új tranzakció kezdetét. Az ettől a ponttól végrehajtott összes adatbázis-módosítás (INSERT, UPDATE, DELETE) a tranzakció részévé válik, és addig nem válik véglegessé, amíg a tranzakciót nem véglegesítik.
• COMMIT: Ez a parancs véglegesíti a tranzakciót. Az összes, a tranzakción belül végrehajtott módosítás véglegesen rögzítésre kerül az adatbázisban, és láthatóvá válik más tranzakciók számára. Ezt követően a rendszer egy új konzisztens állapotba kerül.
• ROLLBACK: Ez a parancs visszavonja a tranzakciót. Az összes, a tranzakción belül végrehajtott módosítás törlődik, és az adatbázis visszatér a tranzakció előtti állapotba. Ez akkor fordul elő, ha hiba lép fel, vagy ha a tranzakció valamilyen okból nem fejezhető be sikeresen.
• SAVEPOINT: Ez a parancs lehetővé teszi, hogy egy tranzakción belül „mentési pontokat” hozzunk létre. Ha egy részleges hibát észlelünk, lehetőségünk van csak egy bizonyos mentési pontig visszagörgetni a tranzakciót (ROLLBACK TO SAVEPOINT), ahelyett, hogy az egész tranzakciót visszavonnánk. Ez rugalmasabb hibakezelést tesz lehetővé bonyolultabb tranzakciók esetén.

A tranzakciók megfelelő használata kritikus fontosságú a hibatűrő és megbízható alkalmazások építésében. A fejlesztőknek tisztában kell lenniük azzal, hogy mikor van szükség explicit tranzakciókezelésre, és hogyan kell helyesen alkalmazni ezeket a parancsokat az adatbázis integritásának fenntartása érdekében.

Tranzakciós naplózás és helyreállítás

A tranzakciós naplózás (transaction logging) az ACID tartóssági (Durability) tulajdonságának alapvető megvalósítási mechanizmusa. A legtöbb relációs adatbázis-kezelő rendszer, és számos más adatkezelő rendszer is, ezt a technikát alkalmazza a rendszerösszeomlások utáni adatvesztés megelőzésére és a helyreállítás biztosítására.

A tranzakciós napló, gyakran write-ahead log (WAL) néven is ismert, egy sorrendben hozzáfűzhető fájl, amely az összes adatbázis-módosítást rögzíti, mielőtt azok ténylegesen az adatfájlokba kerülnének. Ez a „mielőtt írnánk” elv biztosítja, hogy ha a rendszer összeomlik, mielőtt a változások az adatfájlokba íródtak volna, a naplóban akkor is megmarad az információ.

A naplóbejegyzések általában a következőket tartalmazzák:

• A tranzakció azonosítója.
• A módosított adatblokk vagy rekord azonosítója.
• Az adat „régi” értéke (undo információ).
• Az adat „új” értéke (redo információ).
• A művelet típusa (INSERT, UPDATE, DELETE).

Rendszerösszeomlás után az adatbázis-kezelő rendszer a tranzakciós napló segítségével hajtja végre a helyreállítást. Ez általában két fázisból áll:

1. Redo fázis: A rendszer végigmegy a naplón, és újra végrehajtja az összes olyan tranzakciót, amelyet sikeresen véglegesítettek (commit), de a változásai még nem kerültek be az adatfájlokba az összeomlás pillanatában. Ez biztosítja a tartósságot.
2. Undo fázis: A rendszer megkeresi azokat a tranzakciókat, amelyek az összeomlás pillanatában még futottak és nem voltak véglegesítve. Ezeknek a tranzakcióknak az összes részleges változását visszavonja a naplóban tárolt „régi” értékek alapján. Ez biztosítja az atomicitást.

Ez a mechanizmus kritikus a modern adatbázisok megbízhatósága szempontjából, és biztosítja, hogy az adatok mindig konzisztens és tartós állapotban maradjanak, még a legsúlyosabb rendszerhibák után is.

Zárolási mechanizmusok és a párhuzamossági problémák

A zárolási mechanizmusok (locking mechanisms) kulcsfontosságúak az ACID izolációs (Isolation) tulajdonságának megvalósításában, különösen a párhuzamosan futó tranzakciók környezetében. Céljuk, hogy megakadályozzák az adatinkonzisztenciát, amely akkor fordulhat elő, ha több tranzakció egyszerre próbálja módosítani ugyanazt az adatot.

A zárolás lényege, hogy amikor egy tranzakció hozzáfér egy adatforráshoz (pl. egy sorhoz, egy táblához, egy adatblokkhoz), zárat helyez rá. Ez a zár megakadályozza, hogy más tranzakciók hozzáférjenek vagy módosítsák ugyanazt az adatot, amíg az első tranzakció nem fejeződik be és fel nem oldja a zárat.

Két fő zártípust különböztetünk meg:

• Megosztott zár (Shared Lock / S-Lock): Ezt a zárat olvasási műveletekhez használják. Több tranzakció is tarthat megosztott zárat ugyanazon az adaton egyidejűleg, mivel az olvasás nem módosítja az adatot, így nem okoz inkonzisztenciát.
• Exkluzív zár (Exclusive Lock / X-Lock): Ezt a zárat írási műveletekhez (UPDATE, DELETE, INSERT) használják. Csak egyetlen tranzakció tarthat exkluzív zárat egy adaton egyszerre. Ha egy tranzakció exkluzív zárat tart egy adaton, más tranzakciók sem olvasni, sem írni nem tudják azt, amíg a zár fel nem oldódik.

A zárolások segítenek megelőzni az alábbi párhuzamossági problémákat:

• Piszkos olvasás (Dirty Read): Egy tranzakció olyan adatot olvas, amelyet egy másik, még nem véglegesített tranzakció írt. Ha az író tranzakciót visszavonják, a piszkos olvasás érvénytelen adatot látott.
• Nem ismételhető olvasás (Non-Repeatable Read): Egy tranzakció kétszer olvas el ugyanazt az adatot, és a két olvasás között egy másik tranzakció módosítja azt. Az eredmény az, hogy a második olvasás eltér az elsőtől.
• Fantom olvasás (Phantom Read): Egy tranzakció kétszer futtat ugyanazon feltételekkel egy lekérdezést, és a két lekérdezés között egy másik tranzakció új sorokat szúr be vagy töröl, amelyek megfelelnek a feltételeknek. Az eredmény az, hogy a második lekérdezés más sorokat ad vissza.

A zárolási mechanizmusok implementációja összetett, és magában foglalja a kétfázisú zárolási protokollt (2PL – Two-Phase Locking), amely garantálja a sorosíthatóságot. A 2PL szerint a tranzakciók két fázisban működnek: egy növekvő fázisban, amikor zárakat szereznek, és egy csökkenő fázisban, amikor feloldják azokat. A csökkenő fázis megkezdése után már nem szerezhetők új zárak.

Bár a zárolás hatékonyan biztosítja az izolációt, hátránya, hogy csökkentheti a rendszer párhuzamossági teljesítményét, és deadlockokhoz (holtpontokhoz) vezethet, amikor két vagy több tranzakció kölcsönösen vár egymásra egy-egy zár feloldásáért.

Tranzakciós izolációs szintek az SQL-ben

Az SQL szabvány definiál négy tranzakciós izolációs szintet, amelyek különböző kompromisszumokat kínálnak a párhuzamosság és a konzisztencia között. Ezek a szintek határozzák meg, hogy egy tranzakció mennyire lesz elszigetelt a többi, párhuzamosan futó tranzakció hatásaitól. Minél magasabb az izolációs szint, annál kevesebb párhuzamossági probléma fordul elő, de annál nagyobb a teljesítménycsökkenés.

Az izolációs szintek a következőek, a legalacsonyabbtól a legmagasabbig:

1. Read Uncommitted (Olvassa el a nem véglegesített adatokat):
   • Ez a legalacsonyabb izolációs szint.
   • Lehetővé teszi a piszkos olvasást (dirty read). Egy tranzakció láthatja egy másik, még nem véglegesített tranzakció által írt adatokat. Ha az író tranzakciót visszavonják, az olvasó tranzakció érvénytelen adatot látott.
   • Nem akadályozza meg a nem ismételhető olvasást és a fantom olvasást sem.
   • Ritkán használják kritikus üzleti rendszerekben, mert súlyos inkonzisztenciákhoz vezethet. Leginkább csak olyan esetekben, ahol a sebesség a legfontosabb, és az adatok pontossága másodlagos.
2. Read Committed (Olvassa el a véglegesített adatokat):
   • Ez a leggyakrabban használt alapértelmezett izolációs szint sok adatbázisban (pl. PostgreSQL, Oracle).
   • Megakadályozza a piszkos olvasást, mert csak a véglegesített adatokat láthatja.
   • Lehetővé teszi a nem ismételhető olvasást (non-repeatable read) és a fantom olvasást (phantom read). Ha egy tranzakció kétszer olvas el egy sort, és közben egy másik tranzakció módosítja és véglegesíti azt, a második olvasás eltérő eredményt ad.
3. Repeatable Read (Ismételhető olvasás):
   • Megakadályozza a piszkos olvasást és a nem ismételhető olvasást. Ha egy tranzakció egyszer elolvas egy sort, és később újra elolvassa ugyanazt a sort, az eredmény azonos lesz, még akkor is, ha közben más tranzakciók módosítják és véglegesítik azt.
   • Ez általában sorzárolással (row locking) vagy MVCC (Multi-Version Concurrency Control) mechanizmusokkal érhető el.
   • Lehetővé teszi a fantom olvasást (phantom read). Ha egy tranzakció egy tartományon belül futtat lekérdezést, és egy másik tranzakció új sorokat szúr be, amelyek megfelelnek a tartománynak, a második lekérdezés több sort adhat vissza.
4. Serializable (Sorosítható):
   • Ez a legmagasabb izolációs szint, amely teljes mértékben biztosítja az ACID izolációs tulajdonságát.
   • Megakadályozza az összes párhuzamossági problémát: piszkos olvasást, nem ismételhető olvasást és fantom olvasást is.
   • A tranzakciók úgy viselkednek, mintha sorosan (egymás után) futnának, még akkor is, ha valójában párhuzamosan hajtódnak végre.
   • Ez a leglassabb és leginkább erőforrás-igényes szint, mivel gyakran táblaszárolást (table locking) vagy komplexebb MVCC mechanizmusokat igényel. Csak akkor alkalmazzák, ha a legszigorúbb adatkonzisztencia feltétlenül szükséges, és a teljesítmény másodlagos.

A megfelelő izolációs szint kiválasztása kritikus fontosságú. Túl alacsony szint adatinkonzisztenciához vezethet, míg túl magas szint feleslegesen lassíthatja a rendszert. A fejlesztőknek alaposan mérlegelniük kell az alkalmazás igényeit és a rendelkezésre álló adatbázis-kezelő rendszer képességeit.

A deadlock jelenség és kezelési stratégiák

A deadlock (holtpont) egy olyan állapot a párhuzamos tranzakciók környezetében, amikor két vagy több tranzakció kölcsönösen