{"id":30878,"date":"2019-10-31T21:37:56","date_gmt":"2019-10-31T18:37:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-i-mehanizmy-ih-kontrolya\/"},"modified":"2019-10-31T21:37:56","modified_gmt":"2019-10-31T18:37:56","slug":"tranzaktsii-i-mehanizmy-ih-kontrolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transaktioner och deras kontrollmekanismer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transaktioner<\/h2>\n

<\/p>\n

En transaktion \u00e4r en sekvens av operationer \u00f6ver data som har en b\u00f6rjan och ett slut.<\/h4>\n

\nEn transaktion \u00e4r en sekventiell utf\u00f6ring av l\u00e4s- och skrivoperationer. Avslutningen av en transaktion kan antingen vara att spara \u00e4ndringar (commit) eller att \u00e5ngra \u00e4ndringar (rollback). N\u00e4r det g\u00e4ller databaser \u00e4r en transaktion flera f\u00f6rfr\u00e5gningar som tolkas som en enskild f\u00f6rfr\u00e5gan.<\/p>\n

Transaktioner m\u00e5ste uppfylla ACID-egenskaperna.<\/h4>\n

\nAtomicitet. En transaktion antingen genomf\u00f6rs helt eller inte alls.<\/p>\n

Konsistens. Vid avslutandet av transaktionen f\u00e5r inga begr\u00e4nsningar som st\u00e4lls p\u00e5 data (till exempel constraints i databasen) brytas. Konsistens inneb\u00e4r att systemet kommer att \u00f6verf\u00f6ras fr\u00e5n ett korrekt tillst\u00e5nd till ett annat korrekt.<\/p>\n

Isolering. Parallellt utf\u00f6rda transaktioner f\u00e5r inte p\u00e5verka varandra, till exempel genom att \u00e4ndra data som en annan transaktion anv\u00e4nder. Resultatet av att parallella transaktioner genomf\u00f6rs ska vara s\u00e5dant att transaktionerna utf\u00f6rdes sekventiellt.<\/p>\n

Best\u00e4ndighet. Efter en commit f\u00e5r inte \u00e4ndringarna g\u00e5 f\u00f6rlorade.
\n<\/a><\/noindex><\/p>\n

Transaktionslogg.<\/h2>\n

<\/p>\n

Loggen lagrar \u00e4ndringar utf\u00f6rda av transaktioner och s\u00e4kerst\u00e4ller atomaritet och best\u00e4ndighet av data vid systemfel.<\/h4>\n

\nLoggen inneh\u00e5ller v\u00e4rdena som data hade f\u00f6re och efter \u00e4ndringen av transaktionen. Write-ahead log-strategin kr\u00e4ver att tidigare v\u00e4rden ska l\u00e4ggas till i loggen innan transaktionen p\u00e5b\u00f6rjas, och slutv\u00e4rden efter att transaktionen har avslutats. Vid ett pl\u00f6tsligt systemstopp l\u00e4ser databasen loggen bakl\u00e4nges och \u00e5ngrar \u00e4ndringar gjorda av transaktionerna. N\u00e4r databasen st\u00f6ter p\u00e5 en avbruten transaktion utf\u00f6rs den och \u00e4ndringar om den g\u00f6rs i loggen. N\u00e4r databasen \u00e4r i det tillst\u00e5nd som r\u00e5dde vid felet l\u00e4ser den loggen fram\u00e5t och \u00e5terst\u00e4ller \u00e4ndringar gjorda av transaktionerna. P\u00e5 s\u00e5 s\u00e4tt bevaras best\u00e4ndigheten av transaktioner som redan har bekr\u00e4ftats och atomariteten av den avbrutna transaktionen.<\/p>\n

En enkel upprepning av felaktiga transaktioner \u00e4r otillr\u00e4cklig f\u00f6r \u00e5terst\u00e4llning. <\/p>\n

Exempel. Anv\u00e4ndarens konto har 500$ och anv\u00e4ndaren v\u00e4ljer att ta ut dem via en bankautomat. Tv\u00e5 transaktioner utf\u00f6rs. Den f\u00f6rsta l\u00e4ser av saldo och om det finns tillr\u00e4ckligt med medel, ger den pengar till anv\u00e4ndaren. Den andra drar den n\u00f6dv\u00e4ndiga summan fr\u00e5n saldot. Anta att det intr\u00e4ffar ett systemfel och den f\u00f6rsta operationen misslyckas, medan den andra lyckas. I det h\u00e4r fallet kan vi inte ge pengar till anv\u00e4ndaren igen utan att \u00e5terst\u00e4lla systemet till det ursprungliga tillst\u00e5ndet med ett positivt saldo.<\/i><\/p>\n

Isoleringsniv\u00e5er<\/h2>\n

<\/p>\n

L\u00e4sa fasta data (Read Committed)<\/h4>\n

\nProblemet med smutsig l\u00e4sning (Dirty Read) ligger i att en transaktion kan l\u00e4sa ett mellanliggande resultat av en annan transaktion.<\/p>\n

Exempel. Startv\u00e4rdet p\u00e5 saldot \u00e4r 0$. T1 l\u00e4gger till 50$ till saldot. T2 l\u00e4ser saldo (50$). T1 \u00e5ngrar \u00e4ndringarna och avslutas. T2 forts\u00e4tter med att ha felaktiga data om saldot.<\/i><\/p>\n

L\u00f6sningen \u00e4r att l\u00e4sa fasta data (Read Committed) som f\u00f6rbjuder att l\u00e4sa data som \u00e4ndrats av en transaktion. Om transaktion A har \u00e4ndrat en upps\u00e4ttning data, s\u00e5 m\u00e5ste transaktion B v\u00e4nta p\u00e5 att transaktion A ska avslutas innan den kan beg\u00e4ra dessa data.<\/p>\n

\u00c5terkommande l\u00e4sning (Repeatable Read)<\/h4>\n

\nProblemet med f\u00f6rlorade f\u00f6r\u00e4ndringar (Lost Updates). T1 sparar \u00e4ndringar ovanp\u00e5 T2:s \u00e4ndringar.<\/p>\n

Exempel. Startv\u00e4rdet p\u00e5 saldot \u00e4r 0$ och tv\u00e5 transaktioner fyller samtidigt p\u00e5 saldot. T1 och T2 l\u00e4ser saldot som \u00e4r 0$. Sedan l\u00e4gger T2 till 200$ till 0$ och sparar resultatet. T1 l\u00e4gger till 100$ till 0$ och sparar resultatet. Det slutgiltiga resultatet \u00e4r 100$ ist\u00e4llet f\u00f6r 300$.<\/i><\/p>\n

Problemet med icke-\u00e5terkommande l\u00e4sning (Unrepeatable Read). \u00c5terkommande l\u00e4sning av samma data ger olika v\u00e4rden.<\/p>\n

Exempel. T1 l\u00e4ser av saldot som \u00e4r 0$. Sedan l\u00e4gger T2 till 50$ till saldot och avslutas. T1 l\u00e4ser om data och uppt\u00e4cker en mismatch med det tidigare resultatet.<\/i><\/p>\n

\u00c5terkommande l\u00e4sning (Repeatable Read) garanterar att en andra l\u00e4sning ger samma resultat. Data som l\u00e4ses av en transaktion f\u00e5r inte \u00e4ndras av andra innan transaktionen \u00e4r avslutad. Om transaktion A l\u00e4ste en viss upps\u00e4ttning data, m\u00e5ste transaktion B v\u00e4nta p\u00e5 att transaktion A ska avslutas innan den kan beg\u00e4ra dessa data.<\/p>\n

Seriell l\u00e4sning (Serializable)<\/h4>\n

\nProblemet med sp\u00f6kl\u00e4sning (Phantom Reads). Tv\u00e5 f\u00f6rfr\u00e5gningar som h\u00e4mtar data baserat p\u00e5 ett visst villkor returnerar olika v\u00e4rden.<\/p>\n

Exempel. T1 beg\u00e4r antal alla anv\u00e4ndare vars saldo \u00e4r st\u00f6rre \u00e4n 0$ men mindre \u00e4n 100$. T2 drar av 1$ fr\u00e5n en anv\u00e4ndare med saldo 101$. T1 utf\u00f6r f\u00f6rfr\u00e5gan igen.<\/i><\/p>\n

Ordnad l\u00e4sning (Serializable). Transaktioner utf\u00f6rs helt sekventiellt. Att uppdatera och l\u00e4gga till poster som faller under s\u00e5dana villkor \u00e4r f\u00f6rbjudet. Om transaktion A beg\u00e4r data fr\u00e5n hela tabellen s\u00e5 fryses hela tabellen f\u00f6r de andra transaktionerna tills transaktion A \u00e4r slutf\u00f6rd.<\/p>\n

Schemal\u00e4ggare (Scheduler)<\/h2>\n

<\/p>\n

Fastst\u00e4ller i vilken ordning operationer skall utf\u00f6ras vid parallella transaktioner.<\/h4>\n

\nS\u00e4kerst\u00e4ller en given niv\u00e5 av isolering. Om resultatet av operationerna inte beror p\u00e5 deras ordning, \u00e4r dessa operationer kommutativa (Permutable). L\u00e4soperationer och operationer p\u00e5 olika data \u00e4r kommutativa. L\u00e4s-skriv och skriv-skriv operationer \u00e4r inte kommutativa. Schemal\u00e4ggarens uppgift \u00e4r att v\u00e4xla mellan operationer utf\u00f6rda av parallella transaktioner s\u00e5 att resultatet blir ekvivalent med sekventiell utf\u00f6rande av transaktionerna.<\/p>\n

Mechanismer f\u00f6r kontroll av parallella uppgifter (Concurrency Control)<\/h2>\n

<\/p>\n

Optimistisk grundar sig p\u00e5 uppt\u00e4ckten och l\u00f6sningen av konflikter, pessimistisk p\u00e5 f\u00f6rebyggande av konflikter.<\/h4>\n

\nVid den optimistiska metoden f\u00e5r flera anv\u00e4ndare r\u00e5data kopior. Den som f\u00f6rst slutf\u00f6r redigeringen sparar \u00e4ndringar, medan de andra m\u00e5ste g\u00f6ra en sammanslagning av \u00e4ndringarna. Den optimistiska algoritmen till\u00e5ter en konflikt att intr\u00e4ffa, men systemet m\u00e5ste \u00e5terh\u00e4mta sig efter konflikten.<\/p>\n

Vid den pessimistiska metoden f\u00f6rhindrar den f\u00f6rsta anv\u00e4ndaren som f\u00e5ngar data att andra f\u00e5r \u00e5tkomst. Om konflikter \u00e4r s\u00e4llsynta kan det vara rimligt att v\u00e4lja en optimistisk strategi, eftersom den erbjuder h\u00f6gre niv\u00e5 av parallellism.<\/p>\n

L\u00e5sning (Locking)<\/h2>\n

<\/p>\n

Om en transaktion har l\u00e5st data, m\u00e5ste andra transaktioner v\u00e4nta p\u00e5 att l\u00e5sningen ska h\u00e4vas.<\/h4>\n

\nBlock kan till\u00e4mpas p\u00e5 en databas, tabell, rad eller attribut. Dela l\u00e5s (Shared Lock) kan till\u00e4mpas p\u00e5 samma data av flera transaktioner, vilket till\u00e5ter alla transaktioner (inklusive den som har till\u00e4mpat l\u00e5set) att l\u00e4sa, men f\u00f6rhindrar f\u00f6r\u00e4ndringar och exklusiva l\u00e5s. Exklusiv l\u00e5s (Exclusive Lock) kan endast till\u00e4mpas av en transaktion, vilket till\u00e5ter alla \u00e5tg\u00e4rder av den till\u00e4mpande transaktionen, men f\u00f6rhindrar alla \u00e5tg\u00e4rder fr\u00e5n andra.<\/p>\n

En d\u00f6dl\u00e4ges-situation uppst\u00e5r n\u00e4r transaktioner befinner sig i ett o\u00e4ndligt v\u00e4ntel\u00e4ge.<\/h4>\n

\nExempel. Den f\u00f6rsta transaktionen v\u00e4ntar p\u00e5 att data som f\u00e5ngats av den andra ska frig\u00f6ras, medan den andra v\u00e4ntar p\u00e5 att data som f\u00e5ngats av den f\u00f6rsta ska bli tillg\u00e4ngliga.<\/i><\/p>\n

En optimistisk l\u00f6sning p\u00e5 problemet med d\u00f6dl\u00e4gen till\u00e5ter att en d\u00f6dl\u00e4ge uppst\u00e5r, men \u00e5terst\u00e4ller sedan systemet genom att rulla tillbaka en av transaktionerna som \u00e4r involverade i d\u00f6dl\u00e4get.<\/h4>\n

\nMed j\u00e4mna mellanrum genomf\u00f6rs s\u00f6kningar efter d\u00f6dl\u00e4gen. Ett s\u00e4tt att uppt\u00e4cka dem \u00e4r att bed\u00f6ma tiden, det vill s\u00e4ga att anta att ett d\u00f6dl\u00e4ge har intr\u00e4ffat om en transaktion tar f\u00f6r l\u00e5ng tid. N\u00e4r ett d\u00f6dl\u00e4ge hittas, rullas en av transaktionerna tillbaka, vilket ger andra transaktioner som \u00e4r involverade i d\u00f6dl\u00e4get m\u00f6jlighet att slutf\u00f6ras. Valet av offer kan baseras p\u00e5 kostnaden f\u00f6r transaktionerna eller deras \u00e5lder (Wait-Die och Wound-wait scheman). <\/p>\n

Varje transaktion T<\/b> tilldelas en tidsst\u00e4mpel TS<\/b> som inneh\u00e5ller tiden f\u00f6r n\u00e4r transaktionen startade.<\/p>\n

Wait-Die. <\/p>\n

Om TS(Ti)<\/b> < TS(Tj)<\/b>, s\u00e5 Ti<\/b> v\u00e4ntar, annars Ti<\/b> rullas tillbaka och b\u00f6rjar om med samma tidsst\u00e4mpel.<\/u><\/p>\n

Om en yngre transaktion har f\u00e5ngat en resurs, och en \u00e4ldre beg\u00e4r samma resurs, till\u00e5ts den \u00e4ldre transaktionen att v\u00e4nta. Om den \u00e4ldre transaktionen har f\u00e5ngat resursen, kommer den yngre transaktionen som beg\u00e4r denna resurs att rullas tillbaka.<\/p>\n

Wound-wait. <\/p>\n

Om TS(Ti)<\/b> < TS(Tj)<\/b>, s\u00e5 Tj<\/b> rullas tillbaka och b\u00f6rjar om med samma tidsst\u00e4mpel, annars Ti<\/b> v\u00e4ntar.<\/u><\/p>\n

Om en yngre transaktion har tagit kontroll \u00f6ver en resurs och en \u00e4ldre transaktion beg\u00e4r samma resurs, kommer den yngre transaktionen att \u00e5terst\u00e4llas. Om en \u00e4ldre transaktion har tagit kontroll \u00f6ver en resurs, till\u00e5ts den yngre transaktionen som beg\u00e4r den resursen att v\u00e4nta. Valet av offer baserat p\u00e5 \u00e5lder f\u00f6rhindrar uppkomsten av d\u00f6dl\u00e4gen, men rullar tillbaka transaktioner som inte \u00e4r i ett d\u00f6dl\u00e4ge. Problemet \u00e4r att transaktioner kan rullas tillbaka flera g\u00e5nger, eftersom en \u00e4ldre transaktion kan h\u00e5lla resursen under l\u00e5ng tid.<\/p>\n

En pessimistisk l\u00f6sning p\u00e5 problemet med d\u00f6dl\u00e4gen till\u00e5ter inte att en transaktion p\u00e5b\u00f6rjar sin execution om det finns en risk f\u00f6r d\u00f6dl\u00e4ge.<\/h4>\n

\nF\u00f6r att uppt\u00e4cka d\u00f6dl\u00e4gen byggs en graf (v\u00e4ntande graf, wait-for-graph) d\u00e4r noderna \u00e4r transaktioner och kanterna \u00e4r riktade fr\u00e5n transaktioner som v\u00e4ntar p\u00e5 frig\u00f6rande av data till transaktionerna som har tagit dessa data. Det anses att ett d\u00f6dl\u00e4ge har intr\u00e4ffat om grafen har cykler. Att bygga en v\u00e4ntande graf, s\u00e4rskilt i distribuerade databaser, \u00e4r en kostsam process.<\/p>\n

Tv\u00e5fasl\u00e5sning \u00e4r att f\u00f6rhindra d\u00f6dl\u00e4gen genom att ta kontroll \u00f6ver alla resurser som anv\u00e4nds av transaktionen i b\u00f6rjan av transaktionen och frig\u00f6ra dem i slutet.<\/h4>\n

\nAlla blockerande operationer m\u00e5ste f\u00f6reg\u00e5 den f\u00f6rsta avblockerande. Den har tv\u00e5 faser \u2014 Growing Phase d\u00e4r resurser ackumuleras och Shrinking Phase d\u00e4r resurser frig\u00f6rs. Om det inte g\u00e5r att ta kontroll \u00f6ver en av resurserna b\u00f6rjar transaktionen om fr\u00e5n b\u00f6rjan. Det kan uppst\u00e5 situationer d\u00e4r en transaktion inte kan ta kontroll \u00f6ver n\u00f6dv\u00e4ndiga resurser, till exempel om flera transaktioner konkurrerar om samma resurser.<\/p>\n

Tv\u00e5fascommit s\u00e4kerst\u00e4ller att commit utf\u00f6rs p\u00e5 alla repliker av databasen.<\/h4>\n

\nVarje databas registrerar information om de data som kommer att \u00e4ndras i loggen och svarar koordinatorn med OK (Voting Phase). N\u00e4r alla har svarat okej skickar koordinatorn en signal som \u00e5l\u00e4gger alla att utf\u00f6ra commit. Efter commit servern<\/a> svarar de okej; om n\u00e5gon inte svarade okej, skickar koordinatorn en signal f\u00f6r att avbryta \u00e4ndringarna till alla servrar (Completion Phase).<\/p>\n

Metod f\u00f6r tidsst\u00e4mplar<\/h2>\n

<\/p>\n

En \u00e4ldre transaktion rullas tillbaka vid f\u00f6rs\u00f6k att f\u00e5 \u00e5tkomst till data som anv\u00e4nds av en yngre transaktion.<\/h4>\n

\nVarje transaktion tilldelas en tidsst\u00e4mpel TS<\/b> som motsvarar starttiden f\u00f6r utf\u00f6randet. Om Ti<\/b> \u00e4ldre Tj<\/b>, s\u00e5 TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

N\u00e4r en transaktion rullas tillbaka tilldelas den en ny tidsst\u00e4mpel. Varje databasobjekt Q<\/b> som p\u00e5verkas av transaktionen m\u00e4rks med tv\u00e5 st\u00e4mplar. W-TS(Q)<\/b> \u2014 tidsst\u00e4mpeln f\u00f6r den yngsta transaktionen som framg\u00e5ngsrikt har skrivit Q<\/b>. R-TS(Q)<\/b> \u2014 tidsst\u00e4mpeln f\u00f6r den yngsta transaktionen som har utf\u00f6rt en l\u00e4soperation Q<\/b>.<\/p>\n

N\u00e4r transaktionen T<\/b> beg\u00e4r att l\u00e4sa data Q<\/b> finns tv\u00e5 alternativ.<\/p>\n

Om TS(T)<\/b> < W-TS(Q)<\/b>, det vill s\u00e4ga om datan har uppdaterats av en yngre transaktion, s\u00e5 rullas transaktionen T<\/b> tillbaka.<\/u><\/p>\n

Om TS(T)<\/b> >= W-TS(Q)<\/b>, d\u00e5 utf\u00f6rs l\u00e4sningen och R-TS(Q)<\/b> att skapa MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

N\u00e4r transaktionen T<\/b> beg\u00e4r att \u00e4ndra data Q<\/b> finns tv\u00e5 alternativ. <\/p>\n

Om TS(T)<\/b> < R-TS(Q)<\/b>, det vill s\u00e4ga att datan redan har l\u00e4sts av en yngre transaktion och om en \u00e4ndring genomf\u00f6rs, s\u00e5 uppst\u00e5r en konflikt. Transaktionen T<\/b> tillbaka. <\/u><\/p>\n

Om TS(T)<\/b> < W-TS(Q)<\/b>, det vill s\u00e4ga att transaktionen f\u00f6rs\u00f6ker skriva \u00f6ver ett nyare v\u00e4rde, transaktionen T rullas tillbaka. I \u00f6vriga fall genomf\u00f6rs \u00e4ndringen och W-TS(Q)<\/b> blir lika med TS(T)<\/b>.<\/u><\/p>\n

Det kr\u00e4vs inget kostsamt byggande av v\u00e4ntediagram. \u00c4ldre transaktioner beror p\u00e5 yngre, och d\u00e4rf\u00f6r finns det inga cykler i v\u00e4ntediagrammet. Det finns inga d\u00f6dl\u00e4gen, eftersom transaktionerna inte v\u00e4ntar, utan rullas tillbaka direkt. Kaskad\u00e5terst\u00e4llningar kan f\u00f6rekomma. Om Ti<\/b> rullas tillbaka, och Tj<\/b> har l\u00e4st de data som den \u00e4ndrade Ti<\/b>, s\u00e5 Tj<\/b> m\u00e5ste ocks\u00e5 rullas tillbaka. Om detta sker Tj<\/b> redan har beg\u00e5tts, s\u00e5 intr\u00e4ffar ett brott mot stabilitetsprincipen.<\/p>\n

En l\u00f6sning p\u00e5 kaskad\u00e5terst\u00e4llningar. Transaktionen utf\u00f6r alla skrivoperationer i slutet, och \u00f6vriga transaktioner m\u00e5ste v\u00e4nta p\u00e5 att denna operation ska slutf\u00f6ras. Transaktioner v\u00e4ntar p\u00e5 commit innan de l\u00e4ser.<\/p>\n

Thomas write rule \u2014 en variant av tidsst\u00e4mpelmetoden d\u00e4r data som har uppdaterats av en yngre transaktion inte f\u00e5r skrivas \u00f6ver av en \u00e4ldre<\/h4>\n

\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30878","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Transaktioner och mekanismer f\u00f6r deras kontroll | ProHoster","description":"En transaktion \u00e4r en sekvens av operationer p\u00e5 data som har en b\u00f6rjan och ett slut. En transaktion \u00e4r sekventiell utf\u00f6rande av l\u00e4s- och skrivoperationer.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0438 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0438\u0445 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f | ProHoster","og:description":"\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:56+00:00","article:modified_time":"2019-10-31T18:37:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:38","updated":"2026-02-22 15:31:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransaktion T<\/b> beg\u00e4r att \u00e4ndra data Q<\/b>. Om TS(T)<\/b> < W-TS(Q)<\/b>, det vill s\u00e4ga att transaktionen f\u00f6rs\u00f6ker skriva \u00f6ver ett nyare v\u00e4rde, s\u00e5 rullas inte transaktionen T tillbaka som i tidsst\u00e4mpelmetoden.
\n
K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"