MySQL tranzakció- és zárolási utasításai. 1. START TRANSACTION, COMMIT és ROLLBACK szintaxis

Átírás

1 1/23 MySQL tranzakció- és zárolási utasításai 1. START TRANSACTION, COMMIT és ROLLBACK szintaxis 2. Utasítások, melyeket nem lehet visszaforgatni 3. Utasítások, amelyek implicit végrehajtást vonnak maguk után (COMMIT) 4. SAVEPOINT és ROLLBACK TO SAVEPOINT szintaxisa 5. LOCK TABLES és UNLOCK TABLES szintaxisa 5.1. Interakció a Table Locking és Tranzakciók között 5.2. Lock Tables és Triggerek 5.3. Más tábla lezárási jegyzetek 6. SET TRANSACTION szintaxis 7. XA tranzakciók 7.1. XA tranzakció SQL szintaxisa 7.2. XA tranzakció állapotok 1. START TRANSACTION, COMMIT és ROLLBACK szintaxis START TRANSACTION [WITH CONSISTENT SNAPSHOT] BEGIN [WORK] COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE] SET autocommit = {0 1} A START TRANSACTION vagy BEGIN direktívával kezdődik egy új tranzakció. COMMIT elköveti (befejezi) a kurrens tranzakciót, az általa végzett változtatások véglegesek lesznek. A ROLLBACK visszaforgatja az akuális tranzakciót, érvénytelenítve a változásokat, melyek általa lettek volna. A SET autocommit nyilatkozat átállítja az autocommit alapértelmezést a kurrens session-ra. Az opcionális WORK kulcsszót a COMMIT és ROLLBACK miatt használjuk, amint a CHAIN és RELEASE záradékok. CHAIN és RELEASE használható mint pótlólagos ellenőrzése a tranzakció végrehajtásánk. A completion_type rendszerváltozó értéke meghatározza az alapértelmezett kitöltési viselkedést. Megjegyzés Egy tárolt program esetén (tárolt eljárások és függvények, triggerek és események), az elemző úgy tárgyalja BEGIN [WORK] ot, mint egy BEGIN... END blokkot. Kezdjünk el egy tranzakciót egy ilyen környezetben a START TRANSACTION direktívával inkább. A AND CHAIN záradék egy új tranzakció kezdetét okozza, amint a kurrens befejeződik és az új tranzakciónak ugyanaz az elkülönítési szintje, mint a kurrensé. A RELEASE záradék azt eredményezi, hogy a szerver lekapcsolódjon a kurrens kliens session-ról, miután befejezi a kurrens tranzakciót. Belevéve a NO kulcsszót felülírja a CHAIN vagy RELEASE kitöltést, ami hasznos lehet, ha a

2 2/23 completion_type rendszerváltozó a láncolásra vagy a kitöltés kikapcsolásra van állítva alapértelmezetten. Alapérelmezve, a MSQLben az autocommit mód bekapcsolása van érvényben. Ez azt jelenti, hogy mihelyt egy olyan utasítást hajtunk végre, amelyik felülír (módosít) egy táblát, a MySQL tárolja a módosítást a lemezen, hogy állandóvá tegye. Hogy kikapcsoljuk az autocommit módot, használjuk a következő utasítást: SET autocommit=0; Miután kikapcsoltuk az autocommit módot úgy, hogy az autocommit változót zéróra állítottuk, a tranzakció-biztonságos táblákra ( mint az InnoDB vagy a NDBCLUSTER) nem egyből érvényes. El kell végezni a COMMIT utasítást, hogy a változás a lemezen is tárlódjon vagy ROLLBACK utsítást kell kiadni hogy a változásokat figyelmen kívül hagyjuk. Hogy kikapcsoljuk az autocommit módot egy egyszeri utasítás sorra, használjuk a START TRANSACTION záradékot: START TRANSACTION; FROM table1 WHERE type=1; UPDATE table2 SET summary=@a WHERE type=1; COMMIT; A START TRANSACTION használatával, autocommit megmarad kikapcsolt állapotban, amíg befejezzük a trazakciót COMMIT vagy ROLLBACK el. Utána az autocommit mód visszavált az előző állapotba. BEGIN és BEGIN WORK úgy használjuk, mint a START TRANSACTION álnevet, hogy trazakciót indítsunk. START TRANSACTION egy tadard SQL szintaxis és az ad-hoc tranzakciók kezdéséhez ajánlják. Fontos Több API, amit MySQL kliens alkalmazás írásához használunk (mint a JDBC) saját eljárást biztosít a tranzakció kezdéshez, amelyiket sokszor a START TRANSACTION utasítás helyett használjuk a klienstől. A BEGIN záradék különbözik a BEGIN kulcsszó használatától, amelyik egy BEGIN... END összetett utasítás kezdetét jelenti. Az utóbbi nem jelez tranzakció kezdetet. Kezdetünk egy tranzakciót emígy is: START TRANSACTION WITH CONSISTENT SNAPSHOT; A WITH CONSISTENT SNAPSHOT feltétel elindít egy konszisztens olvasást azon tároló motrokhoz, amlyek képesek erre. Ez csak az InnoDB motorra érvényes. A hatása ugyanaz mintha kiadunk egy START TRANSACTION amit követ egy SELECT egy InnoDB táblából. A WITH CONSISTENT SNAPSHOT záradék nem változtatja meg a kurrens tranzakció elkülönítési szintjét, ezért csak akkor

3 3/23 biztosít egy konszisztens pillanatnyi állapotot ha az elkülönítési szint olyan, amelyik megengedi a konszisztens olvasást (REPEATABLE READ vagy SERIALIZABLE). Egy tranzakció kezdete minden folyamatban lévő tranzakciót finalizál. Egy tranzakció kezdése tábla zárolás feloldását jelenti, amit a LOCK TABLES által kaptunk, mintha egy UNLOCK TABLES utastást hajtottunk volna végre. Tranzakció kezdése nem szabadít fel egy globális olvasási zárolást, amelyet FLUSH TABLES WITH READ LOCK által kaptunk. Jobb eredmény elérése céljából a tranzakciókat csak egy tranzakció-biztos tároló motorral érdemes elvégezni. Másképp a következő problémák jelentkezhetnek: Ha a használt táblák több tranzakció-biztos tároló motor elemei (mint InnoDB vagy Falcon), és a tranzakció elkülönítési szint nem SERIALIZABLE, lehetséges, hogy amikor egyik tanzakció befejeződik, egy másik folyamatban levő tranzakció, amelyik ugyanazokat a táblákat használja csak egyes változtatásokat fog látni az előző tranzakcióból. Ez azt jelenti, hogy a kevert motorok használata nem garantálja az atomosságot, így nem következetes adatok keletkezhetek. (Ha a kevert-motros tranzakciók nem gyakoriak, használhatjuk a SET TRANSACTION ISOLATION LEVEL direktívát, hogy beállítsuk az elkülönítési szintet SERIALIZABLE egy tranzakciós bázisra, amint szükséges.) Ha olyan táblákat használunk, amelyek nem tranzakció-biztosak egy tranzakcióban, a változtatások ezekben a táblákban egyszer tárolódnak, tekintet nélkül az autocommit mód beállítására. Ha egy ROLLBACK záradékot használunk, miután módosítottunk egy nem tranzakcionális táblát egy tranzakción belül, egy ER_WARNING_NOT_COMPLETE_ROLLBACK figyelmeztetés lép fel. A tranzakció-biztos táblákon elvégzett módosítások visszaforgatásra kerülnek, de semmilyen változtatás nem történik a nem ranzakció-biztos táblákban. Minden tranzakciót egy bináris logban tartjuk egy tartományban a COMMIT. ig. Azon tranzaciók amelyek visszaforgatásra kerülnek nincsenek bejegyezve. (Kivétel: Nem tranzakcióbiztos táblákon végzett módosításokat nem lehet visszaforgatni. Ha egy tranzakció, amely visszaforgatásra kerül tartalmaz módosíásokat nem tranzakcióbiztos táblákra, az egész tranzakció ROLLBACK záradékkal kerül bejegyzésre, hogy biztosítva legyen az, hogy a nem tranzakcióbiztos táblák módosításáról másodpéldány készül.) Megváltoztathatjuk az elkülönítési sintet a tranzakcióknak a SET TRANSACTION ISOLATION LEVEL el. A visszaforgatás lassú operáció lehet amelyik implicit, kérés nélkül megjelenhet (például, mikor hiba fordul elé). Ezért a SHOW PROCESSLIST kimutatja airolling back t a State oszlopában a

4 4/23 session-nak, nemcsak az explicit visszaforgatás során, amit a ROLLBACK okoz hanem implicit visszaforgatás esetben is. 2. Utasítások, melyeket nem lehet visszaforgatni Egyes záradékokat nem lehet visszaforgatni. Általában, ezek adatdefiniáló utasítások, mint az adatbázisok készítése és eldobása, azok, amelyek elkészítenek, eldobnak vagy módosítanak táblákat vagy tárolt eljárásokat. Megtervezhetjük úgy a trankciónkat, hogy ne tartalmazzon ilyen utasításokat. Ha használunk a tranzakció elején olyan utasítást, amelyiket nem lehet visszaforgatni és azután egy másik utasítás nem végződik el, a tranzakció teljes hatását nem lehet visszaforgatni ez esetben használva a ROLLBACK záradékot. 3. Utasítások, amelyek implicit végrehajtást vonnak maguk után (COMMIT) A listázott utasítások ebből a fejezetből (és mind szinonímái) implicit módon befejz egy tranzakciót, mint a COMMIT indítása mielőtt indítanánk egy utasítást. Adatdefiníciós utasítások, melyek adatbázis objektumokat definiálnak vagy módosítnak. (Data definition language (DDL) statements that define or modify database objects.) ALTER DATABASE... UPGRADE DATA DIRECTORY NAME, ALTER EVENT, ALTER PROCEDURE, ALTER TABLE, CREATE DATABASE, CREATE EVENT, CREATE INDEX,CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP EVENT, DROP INDEX,DROP PROCEDURE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. ALTER FUNCTION, CREATE FUNCTION és DROP FUNCTION ugyancsak implicit végrehajtást idéznek elő, mikor tárolt függvényekkel használjuk, de nem az UDF el (felhasználó által definiált függvény). (ALTER FUNCTION használata kizárólag a tárolt függgvényekkel kapcsolatos.) ALTER TABLE, CREATE TABLE, és DROP TABLE nem implikálja a végrehajtást, ha a TEMPORARY kulcsszót használjuk. (Ez nem érvényes más temporális tábákkal való műveleteknél, mint CREATE INDEX, amelyik végrehajtást eredményez.) Habár az implicit végrehajtás nem kerül sorra, az utasítás nem forgatható vissza. Ezért az ilyen utasítások használata meg fogja szegni a tranzakció atomicitását: Például, ha használjuk a CREATE TEMPORARY TABLE utasítást és visszaforgatjuk a tranzakciót, a temporális tábla létezni fog. A CREATE TABLE utasítás az InnoDB ben úgy van kezelve, mint egy egyszerű trazakció. Ez azt jelenti, hogy a ROLLBACK egy felhasználótól nem állíthata vissza a CREATE TABLE utasítás hatását amit a felhasználó készített a tranzakció folyamán.

5 5/23 MySQL el kezdődően, ALTER VIEW, CREATE TRIGGER, CREATE VIEW, DROP TRIGGER, és DROP VIEW implicit végrehajtást eredményeznek. MySQL el kezdődően, CREATE TABLE... SELECT egy implicit végrehajtást eredményez az utasítás végrehajtása előtt és után, amikor nem temporális táblákat készítünk. (Nem eredményez végrehajtást a CREATE TEMPORARY TABLE... SELECT.) Ez arra való, hogy meglőzzünk egy kimenetet a replikáció során, ahol a táblát el lehet készíteni a masteren egy rollback után, de nem tudjuk beírni a bináris bejegyzésbe, és nem tudjuk megismételni a slave-n. Utasítások, melyek implicit használak vagy módosítanak táblákat a mysql adatbázisban (Statements that implicitly use or modify tables in the mysql database.) A MySQL el kezdődően a CREATE USER, DROP USER, és RENAME USER implicit végrehajtást eredményeznek. A MySQL el kezdődően, GRANT, REVOKE, és SET PASSWORD utasítások implicit végrehjtást eredményeznek. Tranzakció-kontroll és zárolási utasítások (Transaction-control and locking statements.) BEGIN, LOCK TABLES, SET autocommit = 1 (ha az éték nem 1 már), START TRANSACTION, UNLOCK TABLES. UNLOCK TABLES végrahajtást idéz elő egy tranzakcióban csak akkr ha valamely zárolva volt a LOCK TABLES utasítással. Ez nem jelentkezik az UNLOCK TABLES utasításnál, amelyet a FLUSH TABLES WITH READ LOCK követ, mivel a következő utastások nem igénylik a tábla-szintű zárolást. Tranzakciókat nem lehet egymásba ágyazni. Ez az eredménye az implicit végrehajtásnak, amely minden kurrens tranzakció esetébenn, mikor a START TRANSACTION utasítás végződik el vagy a vele hasonló szinonímákra. Azon utasítások, melyek implicit végrehajtást eredményez nem használhatók egy XA tanzakcióban ha az ACTIVE állapotban van. A BEGIN záradék különbözik a BEGIN kulcsszó használtától amelyik kezdi a BEGIN... END összetett utasítást. Az utóbbi nem vált ki egy implicit végrehajtást. Adat letöltési záradék (Data loading statements.) LOAD DATA INFILE. MySQL előtt, LOAD DATA INFILE implicit végrehajtást idéz elő minden tároló motor esetében. Úgy, mint a MySQL nél, implicit végrehajtást csak azoknál a tábláknál eredményez, amelyek az NDB tároló motrot használják. Adminisztratív utasítások. (Administrative statements.) CACHE INDEX, LOAD INDEX INTO CACHE. MySQL el kezdődően, ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, és REPAIR TABLE implicit végrehajtást eredméyeznek.

6 6/23 4. SAVEPOINT és ROLLBACK TO SAVEPOINT szintaxisa SAVEPOINT identifier ROLLBACK [WORK] TO [SAVEPOINT] identifier RELEASE SAVEPOINT identifier InnoDB támogatja a következő SQL utasításokat SAVEPOINT, ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT és az opcionális WORK kulcsszóval ROLLBACK hez. A SAVEPOINT utasítás beállít egy megnevezett tranzakciós mentési pontot, amelyi neve identifier. Ha a kurrens tranzakciónak van egy mentési pontja ugyanazzal a névvel, a régi mentési cím letörlődik és egy új állítódik be. A ROLLBACK TO SAVEPOINT utasítás visszaforgatta a tranzakciót a nevezett mentési ponthoz a tranzakció befejezése előtt. Azon módosítások, amelyeket a kurrens tranzakció végez a mentési pont után visszaforgatódnak, de az InnoDB nem szabadítja fel a sor zárolásokat, amelyek tárolva voltak a memóriában a mentési pont után. (Egy új sorbeszúráshoz, a zárolási információt a tranzakció ID-je hordozza a sorban; a zárolás nincs külön tárolva a memóriában. Ebben az esetben a sor zárolásának feloldása a visszaállítás során történik.) Azon mentési pontok, amelyek egy későbbi időpontban vannak, mint a megnevezett mentési pont, törlésre kerülnek. Ha a ROLLBACK TO SAVEPOINT stasítás a következő hibát adja vissza, ami azt jelenti, hogy nem létezik az adott névvel azonosított mentési pont: ERROR 1305 (42000): SAVEPOINT identifier does not exist A RELEASE SAVEPOINT utasítás eltávolítja a megnevezett mentési pontot a mentési pontok halmazából a kurrens tranzakcióból. Sem érvényesítés, sem visszaforgatás nem történik. Ez egy olyan hiba, mintha a mentési pon nem is létezne. Minden mentési pont a kurrens tranzakcióból törlésre kerül, ha végrehajtjuk a COMMIT, vagy a ROLLBACK utasítást, amelyek nem nevezik meg a mentési pontot. Egy új mentési pont szintje keletkezik, amikor egy tárolt függvényhívás történik, vagy egy trigger aktiválódik. A mentési pontok az előző szinten elérhetetlenné válnak és nem hoznak be konflikus helyzetet az új szinten. Amikor a függvény vagy a trigger befejződik, minden mentési pont, amelyiket implikált elengedésre kerülnek és az előző mentési pont szintje töltődik vissza.

7 7/23 5. LOCK TABLES és UNLOCK TABLES szintaxisa LOCK TABLES tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type]... lock_type: READ [LOCAL] [LOW_PRIORITY] WRITE UNLOCK TABLES A MySQL megengedi a kliens session-nak hogy explicit módon zároljon táblákat azért, hogy együtt működhessen más sessionokkal a táblák elérésére vagy hogy megelőzze at, hogy más session módosítsa a táblákat azon időszak alatt, amikor a session kizárólagos elérhetőséget kíván. Egy session kéreti vagy felszabadíthatja a zárolást csak ő egymaga. Egy session nem kérhet zárolást egy másik sessionra vagy szabadíthat fel más session zárolását. Zárolás használható, hogy tranzakciókat versenyeztessen vagy hogy nagyobb gyorsaságra tegyen szert a sorok módosításában. Ez ki van fejtve részletesebben ebben a fejezetben. LOCK TABLES explicit megszerez tábla zárolásokat a kurrens kliens sessionra. Tábla zárolásokat kérhetünk az alap táblákra vagy nézetekre. Szükséges a LOCK TABLES privilégium és a SELECT privilégium, hogy minden objektumot zárolhassunk. A nézet zárolásához a LOCK TABLES hozzáadja minden alap táblát, amelyeket a nézet használ a tábla halmazhoz amelyeket zárolni kell, majd automatikusan zárolja őket. Ha egy tábla zárolást explicit a LOCK TABLES utasítással zárolunk, minden tábla, melyet a triggerek használnak implicit zárova lesz. UNLOCK TABLES explicit felszabadít minden tábla zárolást a kurrens sessionban. Egy másik használata az UNLOCK TABLES az, hogy felszabadítsa a globális olvasási zárolást, amelyet a FLUSH TABLES WITH READ LOCK utasítás okozott, amelyik megengedi hogy zároljunk minden táblát minden adatbázisban. Egy tábla zárolás csak ellenőrizetlen olvasás és írás ellen véd, amelyet más session okozhat. Az a session, amelyik a zárolást tartja, akár az olvasási zárolást, tábla típusú műveleteket végezhet, mint a DROP TABLE. Megcsonkított műveletek nem tranzakcióbiztosak, vagyis egy hiba keletkezik ha a session mgpróbál egyet teljesíteni egy aktív tranzakció közben vagy egy tába zárolása alkalmával. A következő tárgyalás a nem-temporary tálákról szól. LOCK TABLES meg van engedve (de hatástalan) egy TEMPORARY táblánál. A táblát el lehet érni szabadon azon session által, amelyben keletkezett, tekintet nélkül ara, hogy más zárolás hatásban lenne. Egy zárolásra sincs szükség ebben az esetben mivel semmilyen más session nem látja a táblát. LOCK TABLES és UNLOCK TABLES nem használhatóak tárolt programok esetében.

8 8/23 Zárolás megszerzési szabályok (Rules for Lock Acquisition) Hogy zárolást szerezünk a folyamatban levő sessionban használjuk a LOCK TABLES utasítást. A kövekező zárolási típusok használhatók: READ [LOCAL] lock: A session amelyik tartja a zárolást olvashatja a tblát (de nem írhatja). Többszörös session olvasásra zárolhatja ugyanazt a táblát ugyanabban az időben. Más sessions olvashatja a táblát anélkül, hogy explicit READ lock-ot kérne. A LOCAL módosító megengedi a konfliktusmentes INSERT utasításoknak (konkurens beszúrások) más sessions részéről való végrahajtását mikor a zárolás tartja. Habár a READ LOCAL nem használható, ha az adatbázist a szerveren kívüli folyamatok által akarjuk irányítani miközben birtokoljuk a zárolást. Az InnoDB tábláknál a READ LOCAL ugyanazt jelenti, mint a READ. [LOW_PRIORITY] WRITE lock: A session, amelyik birtokolja a zárolást olvashatja és írhatja a táblát. Csak a session, melyik birtokolja a zárolást tudja elérni a táblát. Semmilyen más session nem érheti el, míg a zárolást fel nincs oldva. Egy zárolási kérés egy táblára egy másik session által blokálva van, míg a WRITE zárolást birtokolaja. A LOW_PRIORITY módosító befolyásolja a zárolási ütemezést ha a WRITE zárolási kérésnek várnia kell, ahogy leírjuk a továbbiakban. Ha a LOCK TABLES utasításnak várnia kell amíg egy másik session birtokolja a zárolást bármely táblán, leblokálja, míg az összes zárolást meg lehet szerezni. Egy session amelyik zárolást igényel minden zárolást meg kell szerezzen amire szüksége van egy egyetlen LOCK TABLES utasításban. Amíg a zárolások birtokolva vannak, a session csak a zárolt táblákat használhatja. Például, a következő utasítás szekvenciában, egy hiba fog fellépni a t2 elérése miatt, mivel nem volt zárolva a LOCK TABLES utasításban: mysql> LOCK TABLES t1 READ; mysql> SELECT COUNT(*) FROM t1; COUNT(*) mysql> SELECT COUNT(*) FROM t2; ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES

9 9/23 A táblák az INFORMATION_SCHEMA adatbázisban kivételek. Ezeket használhatjuk anélkül, hogy explicit zárolnánk akkor is, ha a session tartalmaz tábla zárolásokat, melyeket a LOCK TABLES utasítással kapott meg. Nem vonatkoztathatunk egy zárolt táblára több alkalommal egy egyetlen lekérdezésbe használva ugyanazt a nevet. Haszáljunk álnevet (alias) és szerezzünk meg különálló zárolást a táblára és minden alter egójára: mysql> LOCK TABLE t WRITE, t AS t1 READ; mysql> INSERT INTO t SELECT * FROM t; ERROR 1100: Table 't' was not locked with LOCK TABLES mysql> INSERT INTO t SELECT * FROM t AS t1; Hiba keletkezik az első INSERT alkalmával, mivel két vonatkoztatás van ugyanarra a zárolt táblára. A második INSERT sikerül, mivel a meghívása a táblának különböző nevet használ. Ha az utasítás egy táblára az álnevével vonatkoztat, kell zárolni a táblát használva ugyanazt az álnevet. Nem működik a tábla zárolása anélül, hogy meghatároznánk az álnevet: mysql> LOCK TABLE t READ; mysql> SELECT * FROM t AS myalias; ERROR 1100: Table 'myalias' was not locked with LOCK TABLES Ennek megfelelően, ha zárolunk egy táblát álnevet használva, az utasításban azt az álnevet kell használnunk: mysql> LOCK TABLE t AS myalias READ; mysql> SELECT * FROM t; ERROR 1100: Table 't' was not locked with LOCK TABLES mysql> SELECT * FROM t AS myalias; WRITE zárolásnak normális esetben nagyobb prioritása van, mint a READ zárolásnak hogy biztosak lehessünk abban, hogy a módosításokat minél hamarabb elvégezhessük. Ez azt jelenti, hogy ha egy session megkap egy READ zárolást és aztán egy más session kér egy WRITE zárolást, a későbbi READ zárolási kérés vár, míg az a session, amelyik kérte a WRITE zárolást megkapja a zárolást és felszabadtja. Egy LOW_PRIORITY WRITE zárolás viszont megengedi a következő READ zárolási kérésnek egy másik sessionból, hogy hamarabb ki legyen szolgálva, míg a LOW_PRIORITY WRITE kérés várakozik. Hasznlhatjuk a LOW_PRIORITY WRITE zárolást akkor, ha bíztosak vagyunk abban, hogy valószínűen lesz olyan időszak, amikor egyetlen session sem rendelkezik a READ l zárolással. Az InnoDB tábláknál a tranzakciós módban (autocommit = 0), egy várakozó LOW_PRIORITY WRITE zárolás úgy viselkedik, mint egy átlagos WRITE zárolás és a következő READ zárolás várakozását eredményezi. LOCK TABLES a következő képpen szerzi meg a zárolásokat: 1. Sorba állítja a zárolásra kerülő táblákat egy belső sorrend szerint. A felhasználó szempontj szerint ez a sorrend nem érhető el.

10 10/23 2. Ha egy tábla olvasásra is és írásra is zárolás kérés érkezik, rakd az írsra való zárolási kérelmet az olvasási zárolás elé. 3. Zárolj egy táblát egyszerre, míg a session megkapja az összes zárolást. Ez az eljárásmód biztosítja, hogy a tábla zárolása beragadás-mentes. Vannak azonban olyan más dolgok, ami miatt figyelni kell erre az eljárásmódra: Ha egy LOW_PRIORITY WRITE zárolást használunk egy táblához azt jelenti, hogy kizárólag a MySQL várakozik erre az egyedi zárolásra, amíg nincs egy session sem, amelyik szeetne egy READ zárolást. Amikor a session megkapja a WRITE zárolást és várakozik hogy megkapja a zárolást a következő tálára a zárolási tábla listában, minden más session várakozik a WRITE zárolás befejezésére. Ha ez egy komoly problémává válik az alkalmazásban, arra kell gondolni, hogy átváltoztassuk egyes tábláinkat tranzakcióbiztos táblákká. Zárolás felszabadítási szabályok (Rules for Lock Release) Amikor a zárolt táblák, melyeket egy session használ feszabadításra kerülnek, egyszerre szabadulnak fel. Egy session felszabadíthatja explicit a zárolásait, vagy a zárolások iplicit szabadulnak fel bizonyos meghatározott feltételek mellett. Egy session felszabadíthatja az ő zárolásait explicitly módon alkalmazva az UNLOCK TABLES. Ha egy session azt eredményezi, hogy egy LOCK TABLES utasítás megkapjon egy zárolást miközben ugyancsak birtokol egy zárolást, a létező zárolását implicit felszaadítja a rendszer, mielőtt az új zárolás jóváhagyódik. Ha egy session elindít egy tranzakciót (például egy START TRANSACTION használatával), egy implicit UNLOCK TABLES kerül végrehajtásra, ami azt eredményezi, hogy a létező zárolások fel lesznek szabadítva. Ha egy kliens session kapcsolata befejeződik akár normálisan, akár abnormálisan, a szerver implicit feloldja az össze tábla zárolásokat, melyeket a session birtokolt (tranzakcionális vagy nem). Ha a kliens újra kapcsolatot létesít, a zárolások nem hatássak többé. Ezenkívül, ha a kliensnek egy aktívtranakciója van, a szerver visszagörgeti a tranzakciót a szétkapcsolásig és ha egy újrakapcsolásra kerül sor, az új session aktiválja az autocommitot. Ebből az okból kifolyólag a kliensek szeretnék használni az auto-reconnect opciót. Ezzel az auto-reconnect hatással, a kliens nincs értesítve az újrakapcsolás tényéről de bármely tábla zárolása vagy a kurrens tranzakció elveszik. Az auto-reconnect kikapcsolt állapotában, ha egy kapcsolat elvész egy hibajelzés keletkezik az elkövetkező utasításvégzés kérésekor. A kliens észlelheti a hibát és megfelelő cselekedetet végezhet, hogy visszakapja a zárolást vagy újrafuttassa a tranzakciót.

11 11/23 Megjegyzés Ha az ALTER TABLE utasítást használunk egy zárolt táblán, zárolás nélkülivé válhat. Példul, ogy ha megpróbálunk egy második ALTER TABLE utasítást, az eredmény egy lehet egy ilyen hiba: Table 'tbl_name' was not locked with LOCK TABLES. Hogy kezelhessük ezeket, zároljuk a táblákat mégegyszer a második struktúramódosítás előtt Interakció a Table Locking és Tranzakciók között LOCK TABLES és UNLOCK TABLES a következő tranzakciók használatakor kerülnek kölcsönhatásba: LOCK TABLES nem tranzakcióbiztos és implicit befejezésre késztet minden aktív tranzakciót, mielőtt zárolná a táblákat. UNLOCK TABLES implicitly befejezésre késztet bármilyen aktív tranzaciót, de csak ha LOCK TABLES volt használva hogy beszerezzék a táblák zárolását. Például, a következő utasítás sorozatban UNLOCK TABLES elengedi a globális olvasási zárolást, de nem véglegesíti a tranzakciót mivel egy tábla zárolás sincs folyamatban: FLUSH TABLES WITH READ LOCK; START TRANSACTION; SELECT... ; UNLOCK TABLES; Tranzakiót kezdve (például a START TRANSACTION használatával) implicit véglegesítést okoz minden kurrens tranzakcióra és felszabadítja a létező zárolásokat. Más utasítások, melyek implicit tranzakció véglegesítést okoznak nem szabadítják ki a létező zárolásokat. A helyes használata a LOCK TABLES és az UNLOCK TABLES tranzakciós tábláknál, mint az InnoDB táblák az, hogy kezdjük a tranzakciót a SET autocommit = 0 (nem START TRANSACTION) és azt kövesse a LOCK TABLES, és ne használjuk az UNLOCK TABLES amíg nem véglegesítjük a tranzakciót explicit módon. Például, ha szükségünk van egy írásra a t1 táblában és egy olvasásra a t2 táblában cselekedhetünk a következő képpen: SET autocommit=0; LOCK TABLES t1 WRITE, t2 READ,...;... do something with tables t1 and t2 here... COMMIT; UNLOCK TABLES; Amikor meghívjuk a LOCK TABLES, az InnoDB belsőleg a saját tábla zárolásait valósítja meg, a MySQL a saját tábla zárolását használja. InnoDB felszabadítja a belső tábla zárolását a következő commit alkalmával, de hogy a MySQL felszabadítsa a tábla zárolásait, meg kell hívnunk az UNLOCK TABLES. Nem szükségszerű, az hogy autocommit = 1, mivel utána az InnoDB felszabadítja a belső tábla zárolásait azonnal, miután meghívta a LOCK TABLES, és

12 12/23 beragadások történhetnek nagyon egyszerűen. InnoDB does nem szerez meg belső tábla zárolást egyáltalán ha autocommit = 1, hogy segítse a régi alkalmazásokat a fölösleges beragadások elkerülésében. ROLLBACK nem oldja fel a tábla zárolásokat. FLUSH TABLES WITH READ LOCK beszerez egy globális olvasási zárolást és nem tábla zárolást, vagyis nem úgy viselkedik, mint a LOCK TABLES és UNLOCK TABLES a tábla zárolással és az implicit véglegesítést Lock Tables és Triggerek Ha egy táblát zárolunk expicit módon a LOCK TABLES utasítással, bármilyen tábla, melyet a triggerek használnak ugyancsak zároltak lesznek implicit módon: A zárolások ugyanakkor vannak felvéve, mint azok, amelyek explicit módon vannak megszerezve, mint a LOCK TABLES utasításban. A zárolás egy táblán, amit egy triggerben használunk függ attól, hogy a tábla csak olvasásra van-e használva. Ha igen, az olvasási zárolás elegendő. Másképp egy írási zárolást használunk. Ha egy tábla explicit zárolást igényel az olvasásra a LOCK TABLES segítségével, de szükséges zárolni az írásra, mivel módosítható egy triggeren belül, egy írási zárolás lesz elvéve, mintsem egy olvasási zárolás. (Azaz, egy implicit írási zárolás szükséges a táblák megjelenése alkalmából egy triggeren belül, ez egy olvasási zárolási kérést jelent azon táblának, amelyiket konvertálni kell egy írási zárolás kéréshez.) Feltételezva, hogy két táblát szeretnénk zárolni, t1 és t2, használva a következő utasítást: LOCK TABLES t1 WRITE, t2 READ; Ha t1 vagy t2 tartalmaz triggereket, táblákat melyeket triggereken belül használunk ugyancsak zárolva lesznek. Feltételezzük, hogy a t1 tartalmazza a következő triggert: CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROW BEGIN UPDATE t4 SET count = count+1 WHERE id = NEW.id AND EXISTS (SELECT a FROM t3); INSERT INTO t2 VALUES(1, 2); END; Az eredménye a LOCK TABLES utasításnak az, hogy a t1 és t2 zárolva lesznek mivel megjelennek az utasításban because, t3 és t4 zárolva lesznek, mivel a triggeren belül használjuk: t1 írásra van zárolva a WRITE zárolás kérés révén. t2 írásra van zárolva, habár a kérés csak egy READ zárolás. Ez azért jelenik meg, mert t2 részt vesz a trigger megvalósításában, vagyis a egy WRITE kéréssé. READ kérés át van alakítva

13 13/23 t3 olvasásra van zárolva, mivel csak olvasásra van használva a triggeren belül. t4 írásra van zárolva, mivel lehetséges módosításnak van kitéve a tggeren belül Más tábla-lezárási jegyzékek Biztonságosan használhatjuk a KILL-t hogy befejezzünk egy sessiont amelyik vár egy zárolt táblára. Nem szabad zárolni olyan táblákat, amelyeket az INSERT DELAYED használ. Egy INSERT DELAYED ebben az esetben egy hibát eredményez, mivel a beszúrást egy különálló folyamatszálat igényel, nem abban a sessionban amelyik birtokolja a zárolást. Egyes műveletekhez a rendszer táblákat a mysql adatbázisból el kell érni. Például, a HELP utasítás elvárja az elérhetőségét a szerver-oldali segítő tábláknak, és a CONVERT_TZ() talán szükségesnek találja hogy olvassa az időzóna táblákat. A MySQL előtt, hogy egy ilyen műveletet el lehessen végezni, miközben egy LOCK TABLES utasítás hatásban van, zárolni kell ugyancsak a rendszer táblákat explicit módon, vagy egy zárolási hiba lép fel. Az után a szerver implicit olvasásra zárolja a rendszer táblákat, ezét nem kell azt explcit módon zárolni. Ezen táblák tárgyalása úgy fog történni, ahogy ezt leírtuk az előbb: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type Ha explicit szeretnénk egy WRITE zárolást elhelyezni azokon a táblákon, melyek LOCK TABLES utasítás érvényben van, a táblát egyedül tudjuk zárolni; semmi más tábla nem zárolható ugyanazzal az utasításal. A valóságban semmi szükség zárolni a táblákat, mive minden egyes UPDATE utasítás atomi szerkezetű; semmiyen más session nem tud beavatkozni egy kurensen végrehajtásra kerülő SQL utasítással sem. Azonban van egy pár eset amikor a táblák zárolása előnyt jelenthet: Ha több műveletet akarunk futtatni egy MyISAM tábla halmazon, sokkal gyorsabb zárolni a táblákat, melyeket használni akarunk. A MyISAM táblák zárolása felgyorsítja a beszúrást, módosítást, vagy törlést, mivel a MySQL nem gyorsítja (flush) a kulcs kash memóriát a zárolási táblákra, míg az UNLOCK TABLES meghívásra kerül. Normális esetben a kulcs kash memória kiürül minden SQL utasítás után.

14 14/23 A hátulütője a táblák zárolásának az, hogy semmilyen session nem tudja módosítani a READzárolási táblát (beleértve azt is, amelyik birtokolja a zárolást) és semmilyen session nem tud elérni más WRITE-zárolási táblát, csak azt, amelyik birtokolja a zárolást. Ha nem-tranzakciós adatbázis motort tábláit használunk, használnunk kell a LOCK TABLES ha biztosak akarunk lenni, hogy más session nem módosítja a táblákat a SELECT és az UPDATE között. Az itt bemutatott példa igényli a LOCK TABLES hogy biztosan elvégzésre kerüljön: LOCK TABLES trans READ, customer WRITE; SELECT SUM(value) FROM trans WHERE customer_id=some_id; UPDATE customer SET total_value=sum_from_previous_statement WHERE customer_id=some_id; UNLOCK TABLES; A LOCK TABLES nélkül lhetséges, hogy egy másik session beszúrjon egy új sort a trans táblába a SELECT és az UPDATE utasítások között. Használhatjuk a LOCK TABLES több esetben mikor relatív frissítést használunk (UPDATE customer SETvalue=value+new_value) vagy a LAST_INSERT_ID() függvény. Ugyacsak elkerülhetjük a táblák zárolását ha használjuk a felhasználó-szintű tanácsolt zárolási függvényeket, a GET_LOCK() és RELEASE_LOCK(). Ezen zárolások mentve vannak egy hasító táblában (hash table) a szerver oldalon és implementálva vannak a pthread_mutex_lock() és pthread_mutex_unlock()a gyorsabb sebesség érdekében.

15 15/23 6. SET TRANSACTION szintaxis SET [GLOBAL SESSION] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE } Ez az utasítás beállítja a tranzakció elkülönítési szintjét globális módon, a kurrens sessionra vagy a következő tranzakcióra: A GLOBAL kulcsszó utasítás beállítja az alapértelmezett tranzakciós szintet globálisan minden következő sessionra. Létező sessionok nincsenek befolyásolva ez által. A SESSION kulcsszóval rendelkező utasítás beállítja az alapértelmezett tranzakciós szintet minden következő tranzakcióra, amelyik ezen a sessionon belül hajtódik végre. A SESSION vagy GLOBAL kulcsszón kívül az utasítás beállítja az elkülönítési szintet az elkövetkező (nem elindított) tranzakciókra, melyek az aktuális sessionban lesznek elvégezve. Egy vátoztatás a globális elkülönítési szintben SUPER privilégimot igényel. Bármely sessionnak joga van megváltoztatni az elkülönítési szintet (a tranzakció végreajtása közben is), vagy az ekülönítési szintjét az elkövetkező tranzakcióinak. Hogy beállítsuk a globális elkülönítési szintet a szerver indításához használjuk a --transactionisolation=level opciót a mysqld a parancsértelmezőben vagy egy opciós fájlban. A level (szint) értékek erre az opcióra kötőjeleket használnak mintsem szóközöket, így a lehetséges értékek a READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, vagy SERIALIZABLE. Például, hogy beállítsuk az elkülönítési szinteket REPEATABLE READ-re, használjuk ezeket az utasítás sorokat a [mysqld] részében egy opciós fájlnak: [mysqld] transaction-isolation = REPEATABLE-READ Hogy meghatározzuk a globális és a session tranzakciós elkülönítési szintet a futásidőben, ellenrizzük a tx_isolation renszerváltozó Az InnoDB támogatja az összes elkülönítési szintet, amelyet itt leírunk, amely különböző zárolási stratégiát használnak. Az alapértelmezett szint a REPEATABLE READ. A következő lista bemutatja hogyan támogatja a MySQL a különböző tranzakciós szinteket: READ UNCOMMITTED SELECT utasításokat végrehajtjuk egy nem zárolási szokásként, hanem egy lehetséges előző variánsa a sornak lesz használva. Eképpen, használva az elkülönítési szintet, ilyen olvasások

16 16/23 nem konzisztensek. Ezt úgy is hívják, hogy mocskos olvasás Másképp, ezen elkülönítési szint úgy működik, mint a READ COMMITTED. READ COMMITTED Egy Oracle-tipusú elkülönítési szint tekintetbe véve a konzisztens (nemzárolási) olvasást: Miden konzisztens olvasás, még ugyanazon tranzakción belül is beállítja és olvassa a saját friss pillanatképét. Az olvasási zárolásra (SELECT a FOR UPDATE el vagy LOCK IN SHARE MODE), InnoDB zárolás csak az indexeket veszi fel, kihagyja az üres részeket, mely előtte van és ez megengedi a szabad beszúrását egy új sornak a zárolt bejegyzés után. Az UPDATE és DELETE utasításoknál a zárolás függ attól, hogy az utasítás egy egyedi indexet használ-e egyedi keresési feltételek mellett (mint a WHERE id = 100), vagy egy tartomány tipusú keresési feltételel (mint a WHERE id > 100). Egy egyedi index egy egyedi keresési feltétel mellett, az InnoDB zárolások csak az index rekordokat, nem az előtte levő üres részeket találja meg. A tartomány-tipusú keresések, InnoDB zárolással az index tartományt viszgálja végig, használva az üres zárolási vagy egy következő-kulcs (üres rész plus index-rekord) zárolási vagy blokkolt beszúrásokat más sessionok által az üres helyekről, amit befed a tartomány. Ez szükséges, mivel a fantom sorokat blokkolni kell, hogy a MySQL replikáció és visszanyerés működjön. Megjegyzés A MySQL 5.1 ben, ha a READ COMMITTED elkülönítési szint létezik ezt használatos vagy az innodb_locks_unsafe_for_binlog rendszerváltozó engdélyezve van, nincs InnoDB gap zárolás, kivéve az idegen kulcs megszorítások ellenőrzésére és a többszörös-kulcs ellenőrzésre. Ugyanakkor a sorzárolás a nem összeillő sorokra felszabadítását eredményezik miután a MySQL kiértékeli a WHERE fetételt. A MySQL 5.1, ha használjuk a READ COMMITTED vagy engedélyezzük az innodb_locks_unsafe_for_binlog, kötelezően használni kell a soron-alapuló bináris bépést (logging). REPEATABLE READ Ez az alapértelmezett elkülönítési szint az InnoDB-nek. A konzisztens olvasáshoz jelentős különbség van a READ COMMITTED elkülönítési szinttől: Minden konzisztens olvasás ugyanabban a tranzakcióban beolvassa a pillanatfelvételt, amelyet az első olvasás határozott meg. Ez a megállapodás azt jelenti, hogy ha használunk egy pár síma (nem zárolt) SELECT utasítást ugyanazon a tranzakción belül, ezen SELECT utasítások konzisztensek egymás irányában is.

17 17/23 Az olvasási zárolás (SELECT FOR-ral együtt, UPDATE vagy LOCK IN SHARE MODE), UPDATE és DELETE utasítások, a zárolás függ attól, hogy az utasítás egyedi indexet használ-e egy egyedi keresési feltétellel vagy egy tartomány-tipusú keresési feltételt. Az egyedi index egy egyedi keresési feltétellel az InnoDB zárolások csak az index rekordokat találja, s nem az előttük levő gap-eket. Más keresési feltételek mellett az InnoDB zárolások az index tartományt keresik, használva a gap zárolásokat vagy a következő-kulcs (gap plusz index-rekord) zárolásokat hogy blokkolja a beszúrást más sessionok által a gapbe, amelyeket a tartomány fedi. SERIALIZABLE Ez a szint olyan, mint a REPEATABLE READ, de InnoDB implicit módon konvertál minden síma SELECT utasítást a következőbe SELECT... LOCK IN SHARE MODE ha az autocommit ki van kapcsolva. Ha az autocommit be van kapcsolva, a SELECT a saját tranzakciója. (Ez azt jelenti hogy a síma SELECT kényszerítése arra, hogy blokkolja ha más tranzakció módosítota a kiválasztott sorokat, ki lehet kapcsolni az autocommitot.)

18 18/23 7. XA tranzakciók Az XA tranzakciók támogatása az InnoDB adatbázis motor által történik. A MySQL XA implementáció az X/Open CAE dokumentum Distributed Transaction Processing: The XA Specification n alapszik. Ezt a dokumentumot az The Open Group publikálta és elérhető a A kurrens XA behatárolása le van írva a következő dokumentumokban Section D.5, Restrictions on XA Transactions. A kliens oldalon nincs szükség semmiféle speciális előfetételnek. Az XA interfész gy MSQL szerverhez olyan SQL utasításokból áll, amelyek az XA kulcsszóval kezdődnek. A MySQL kliens programnak alkalmasnak kell lennie, hogy SQL utasításokat küldjön és hogy megértse az XA utasítási interfész szemantikáját. Nincs szükség egy új klies könyvtároz való kapcsolatra. Régebbi klies könyvtárak ugyancsak működni fognak. Kurrensen, a MySQL konnektorok között, a MySQL konnektor/j támogatja az XA-t direkt módon (egy osztály intefészen keresztül, amelyik kezeli az Xan SQL utasítás interfészeket). XA támogatja az osztott tranzakciókat, vagyis azt, hogy több, különálló tranzakciós forrás vehessen rész egy globális tranzakcióban. Tranzakionális források sok esetben ABR-ek de másfajta források is lehetnek. Egy globális tranzakció maga után von egy pár cselekvést, amelyek maguk is tranzació típusúak, de mindnenk sikeresen kell befejeződniük, mint egy csoportnak, vagy mindent vissza kell forgatni. Lényegében ez kitejeszti az ACID tlajdonságot egy szinttel fennebb úgy, hogy a többzörös ACID tarnzakció elvégezhetővé válik, mint egy komponense a globális műveletnek, amelyiknek ugyancsak ACID tulajdonságai vannak. (Habár egy osztott tranzakcióhoz használni kell a SERIALIZABLE izolációs szintet hogy elérjük az ACID tulajdonságokat. Elégséges a REPEATABLE READ használata egy nem osztott tranzakcióhoz, de nem elégséges egy osztott tranzakcióhoz.) Pár példa az osztott tranzakciókra: Egy alkalmazás úgy viselkedhet mint egy integrációs eszköz, amelyik összekombinálja az üzenetküldő szolgáltatást az ABR-el. Az alkalmazás bebiztosítja azt, hogy azon tranzakciók, melyek üzenetküldést, visszakaresést vagy feldlgozást használnak, amelyek ugyancsak tranzakciós adatbázist hasznának, minden egy globális tanzakcióban játszodjék le. Úgy gondolhatnk rá, mint egy tranzakciós re. Egy alkalmazás több adatbázis szerevert használ, mint egy MySQL szerver és egy Oracle szerver (vagy többszörös MySQL szerver), ahol a cselekmények, melyek több szerver használatát fetételezik úgy kell viselkedjenek, mit egy globális tranzakció részei, mintsem különálló lokális trnzakciók minden szerveren.

19 19/23 Egy bank nyilvántartja a számla információit egy ABR-en és elosztja és kapja a pénz bankautomatákon keresztül (ATMs). Szükséges, hogy biztosítsuk, hogy z ATM történései helyesen tükröződjenek a számlákban, de ezt egyedül az ABR nem tudja megoldani. Egy globális tranzakció menedzser integrálja az ATM-t és az adatbázis erőforrásokat, hogy biztosítsa a mindenekfölötti konzisztenciáját a pénzügyi tranzakciónak Azon alkalmazások, melyek globális tranzakciókat használnak egy vagy több Resource Managert és egy Tansaction Managert használnak: Egy Resource Manager (RM) gondoskodik a tranzakcionális erőforrások elérhetőségéről. Egy adatbázis szerver egyfajta resource manager. Lehetővé kell tenni az RM által menedzselt tranzakciók véglegesítését (commit) vagy visszaforgatását (roll back) is. Egy Transaction Manager (TM) koordinája a tranzakciókat, melyek egy globális tranzakció részei. Kommunikál a RMekkel, melyek kezelnek minden tranzakciót. Az egyéni tranzakciók a globális tranzakcióon belül olyanok, mint ágai a globális tranzakcióknak. Globális tranzakciók és az ő ágai egy megnevező sémával vannak azonosítva, melyet később írunk le. A MySQL implementációja az XA MySQL megengedi egy MySQL szervernek hogy egy Resource Managerként viselkedjen,amelyik kezeli az XA tranzakciókat egy globális tranzación keresztül. Egy kliens program, amelyik a MySQL szerverhez kapcsolódik úgy viselkedik, mint egy Transaction Manager. Hogy végrehajthassunk egy globális tranzakciót, szükséges tudni mely komponensek vesznek részt és elvinni minden kompnenst addig a pontig, míg véglegesíteni vagy visszaforgatni lehe. Attól függően, hogy melyik komponens mit jelent arról a képességéről, hogy sikeres legyen, mindeniket vagy véglegesíteni, vagy visszaforgatni kell, mint egy atomi csoportot. Vagyis, vagy minden komponenset véglegesíteni kell, vagy mindeniket visszaforgatni. Hogy menedzselni lehessen egy globális trazakciót, szükéges figyelembe venni, hogy bármelyik komponens vagy az összekötő hálózat is mehibásodhat. A folyamat, mely megvalósítja a globális tranzakciót két-fázisú véglegesítést használ two-phase commit (2PC). Ez azután történik, miután az ágak, melyek a globális tranzakciót alkotják befejezik működésüket. 1. Az első fázisban minden ág felkésül. Vagyis, üzen a TM-nek hogy készen áll a véglegesítésre.. Tipikusan ez azt jelenti, hogy minden RM, amelyik menedzsel egy ágat bejegyzi az ág cselekedetét egy stabil hordozóba. Az ág megadja, hogy meg tudja-e azt valósítani és ezen eredményeket használja fel a második fázisban.

20 20/23 2. A második fázisban a TM megmondja az RMeknek hogy véglegesítsenek vagy forgassák vissza. Ha mindenik ág azt jelenette, hogy fel van készülve és tudja véglegesíteni az ő részét, minden ágnak kiadja a véglegesítési utasítást. Ha valamelyik ág azt jelenti, hogy nem fog tudni véglegesíteni, minden ágnak kiada, hogy forgassa vissza az ő műveletét. Egyes eseekben, egy globális tranzakció használhat egy-fázisú vglegesítést (1PC). Például, mikor egy Transaction Manager azt találja, hogy egy globális tranzakció csak egy tranzakciós erőforrásból áll (vagyis egy ágból), annak az erőforrásnak ugyanakkor ki lehet adni, hogy felkészüljön és véglegesítsen ugyanabban az üzenetben XA tranzakció SQL szintaxisa Hogy végezvigyünk egy XA tranzakciót MySQL alatt, hasnáljuk a következő utasításokat: XA {START BEGIN} xid [JOIN RESUME] XA END xid [SUSPEND [FOR MIGRATE]] XA PREPARE xid XA COMMIT xid [ONE PHASE] XA ROLLBACK xid XA RECOVER Az XA START esetén a JOIN és RESUME záradékok nem támogatottak. Az XA END esetében a SUSPEND [FOR MIGRATE] záradék nem támogatott. Minden XA utasítás egy XA kulcsszóval kezdődik és legtöbbje elvár egy xid értéket. Egy xid egy XA tranzakció azonosító. Megadja azt, hogy melyik tranzakciót alkalmazza az utasítás az xid értékre a kliensek részéről vagy generálja a MySQL szerver. Egy xid érték egytől három részig állhat: xid: gtrid [, bqual [, formatid ]] gtrid egy globális tranzakció azonosító, bqual egy branch (ág) minősítő és formatid egy szám, mely azonosítja a formátumot, melyet a gtrid és bqual értékek használnak. Ahogy a szintaxis is megmutatja, a bqual és formatid opcionálisak. Az aapértelmezett bqual érték '' ha nincs megadva. Az alapértelmezett formatid érték 1 ha nincs megadva. gtrid és bqual kötelező módon sztring literálok kell legyenek, mindenik 64 byte alatti (nem karakerek) hosszúak. gtrid és bqual azonsítókat több féle képpen adhatjuk meg. Használhatunk idézőjelezett sztringet ('ab'), hexa sztringet (0x6162, X'ab'), vagy bit értéket (b'nnnn'). formatid egy jeltelen (unsigned) egész.

21 21/23 A gtrid és bqual értékeket bájtonkét értelmezik a MySQL szerver alatti XA támogató rutinok. Habár, mikor egy SQL utasítást tartalmazó XA záradék elemezve van, a szever különleges karakter halmazzal dolgozik. Hogy biztosak legyünk, írjuk a gtrid és bqual mint hexa szringeket xid értékeit tipikusan a Transaction Manager generálja. A TM által generált értékeknek különbözniük kell más TM által generált értékektől. Egy adott TM fel kell ismerje saját xid értékeit egy listában, melyet a XA RECOVER záradék szolgáltat. XA START xid elindít egy XA tranzakciót az adott xid értékkel. Minden XA tranzakciónak kell legyen egy egyedi xid értéke, hogy azt az értéket semmilyen más XA tranzakció kurrensen ne használja. Az egyediséget úgy írjuk elő, hogy használjuk a gtrid és bqual értékeket. Minden következő XA utasítását az XA tranzakciónak úgy kell azonosítani, hogy használjuk ugyanazt az xid értéket, mint amit megadtunk az XA START záradékban. Ha úgy használjuk azon utasításokat, hogy az xid nem tartozik a létező XA tranzakciók azonosítói közé, egy hiba lép fel. Egy, vagy több XA tranzakció rése lehet valamilyen globális tranzakciónak. Minden XA tranzakció, amel egy globális trnzakció része ugyanzat a gtrid értéket kell használja az xid értéken belül. Ezért, a gtrid értékek globálisan egyediek kell legyenek hogy ne legyen többértelmű hogy melyik globális tranzakcióhoz tartozik egy adott XA tranzakció. A bqual része a xid értéknek különböző kell legyen minden XA tranzakciónál, amelyik egy globális tranzakció része. (Az a követelmény, amelyik at mondja ki, hogy a bqual értékek különbözőek kell legyenek a MySQL XA implementációjának egy korlátozása. Ez nem része az XA specifikációnak.) Az XA RECOVER utasítás visszaad olyan információkat, amelyek a MySQL szerveren mint PREPARED állapotban vannak. A kimenet magába foglal egy sort minden ilyen XA tranzakcióra a szerveren, függetlenül melyik kliens indította el azt. XA RECOVER kimeneti sorai ilyenformán néznek ki (pédául az xid érték a következő részekből áll 'abc', 'def', és 7): mysql> XA RECOVER; formatid gtrid_length bqual_length data abcdef A kimeneti oszlopoknak a következő értelmük van: formatid a formatid része a tranzakció azonosítónak xid gtrid_length a hossza bájtokban a gtrid-nek, amelyik része az xid-nek bqual_length a hossza bájtokban a bqual-nak, mely része az xid-nek data a gtrid és a bqual összevonása, melyek részei az xid-nek

22 22/ XA tranzakció-állapotok Egy XA tranzakció a következő állapotokon megy keresztül: 1. Használjuk az XA START utasítást hogy elindítsunk egy XA tranzakciót és tegyük be az ACTIVE állapotba. 2. Egy ACTIVE XA tranzakcióban, készítsd el az SQL utasításokat, melyek felépítik a tranzakciót, majd készítsd el az XA END utasítást. XA END beteszi a tranzakciót az IDLE állapotba. 3. Egy IDLE XA tranzakcióban, elkészíthetjük vagy az XA PREPARE utasítást vagy XA COMMIT... ONE PHASE utasítást: o o XA PREPARE beteszi a tranzakciót a PREPARED állapotba.egy XA RECOVER utasítás ebben a pontban tartalmazni fogja a tranzakció xid értékét a kimenetében, mivel az XA RECOVER kilistázza az összes XA tranzakciót, amely a PREPARED állapotban van. XA COMMIT... ONE PHASE elkészíti és végrahajtja a tranzakciót. Az xid érték nem lesz listázva az XA RECOVER által, mivel a tranzakció befejeződik. Egy PREPARED XA tranzakcióhoz használhatjuk az XA COMMIT utasítást hogy véglegesítsük és befejezzük a tranzakciót, vagy XA ROLLBACK utasítást, hogy visszaforgassuk és befejezzük a tranzakciót. It egy egyszerű XA tranzakció, amelyik beszúr egy sort egy táblába, mely része egy globális tranzakciónak: mysql> XA START 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO mytable (i) VALUES(10); Query OK, 1 row affected (0.04 sec) mysql> XA END 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> XA PREPARE 'xatest'; Query OK, 0 rows affected (0.00 sec) mysql> XA COMMIT 'xatest'; Query OK, 0 rows affected (0.00 sec) Egy adott kliens connection környezetében, XA tranzakciók és lokális (nem XA) tranzakciók mutuálisan kizárják egymást. Például, ha XA START úgy volt felépítve, hogy elkezdjen egy XA tranzakciót, egy lokális tranzakciót nem lehet elkezdeni, amíg az XA tranzakció nem véglegesítődik vagy nem forgatódik vissza. Viszont ha egy lokális tranzakciót a START TRANSACTION utasítással kezdtünk el, egy XA jegyzék sem használható míg a tranzakció nem véglegesítődik vagy nem forgatódik vissza

23 23/23 Jegyezzük meg, hogy ha egy XA tranzakció az ACTIVE állapotban van, nem lehet felépíteni semmilyen utasítást, mely implicit véglegesítést okoz. Ez megsérti az XA szerződést mivel nem tudjuk visszaforgatni az XA tranzakciót. A következő hibaüzenetet fogjuk kapni, ha megpróbálunk elvégezni egy ilyen utasítást ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state