{"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\/da\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transaktioner og mekanismer til deres kontrol","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transaktioner<\/h2>\n

<\/p>\n

En transaktion er en sekvens af operationer p\u00e5 data, der har en start og en slutning.<\/h4>\n

\nEn transaktion er en sekventiel udf\u00f8relse af l\u00e6se- og skriveoperationer. Afslutningen af en transaktion kan v\u00e6re enten bevaring af \u00e6ndringer (commit) eller annullering af \u00e6ndringer (rollback). I forhold til databaser er en transaktion flere foresp\u00f8rgsler, der betragtes som en enkelt foresp\u00f8rgsel.<\/p>\n

Transaktioner skal opfylde ACID-egenskaberne.<\/h4>\n

\nAtomicitet. En transaktion udf\u00f8res enten fuldst\u00e6ndigt eller slet ikke.<\/p>\n

Konsistens. Ved afslutningen af en transaktion m\u00e5 de begr\u00e6nsninger, der er p\u00e5lagt dataene (f.eks. constraints i databasen), ikke blive overtr\u00e5dt. Konsistens indeb\u00e6rer, at systemet skal overg\u00e5 fra en korrekt tilstand til en anden korrekt.<\/p>\n

Isolation. Parallelt udf\u00f8rte transaktioner m\u00e5 ikke p\u00e5virke hinanden, fx \u00e6ndre data, som en anden transaktion bruger. Resultatet af parallelle transaktioner skal v\u00e6re det samme, som hvis transaktionerne blev udf\u00f8rt sekventielt.<\/p>\n

Holdbarhed. Efter commit m\u00e5 \u00e6ndringer ikke g\u00e5 tabt.
\n<\/a><\/noindex><\/p>\n

Transaktionslog<\/h2>\n

<\/p>\n

Loggen opbevarer \u00e6ndringer foretaget af transaktioner, sikrer atomicitet og holdbarhed af dataene i tilf\u00e6lde af systemfejl.<\/h4>\n

\nLoggen indeholder v\u00e6rdierne, som dataene havde f\u00f8r og efter \u00e6ndringerne blev foretaget af transaktionen. Write-ahead log-strategien kr\u00e6ver, at der tilf\u00f8jes en post til loggen om de tidligere v\u00e6rdier f\u00f8r starten, og om de endelige v\u00e6rdier efter afslutningen af transaktionen. Ved en pludselig systemstop l\u00e6ser databasen loggen bagfra og annullerer \u00e6ndringer foretaget af transaktioner. Hvis den st\u00f8der p\u00e5 en afbrudt transaktion, udf\u00f8rer databasen den og opdaterer loggen om den. I den tilstand, databasen var i p\u00e5 tidspunktet for fejlen, l\u00e6ser databasen loggen i fremadrettet r\u00e6kkef\u00f8lge og genf\u00f8rer \u00e6ndringerne foretaget af transaktioner. Dette sikrer holdbarheden af transaktioner, der allerede er blevet bekr\u00e6ftet, og atomiciteten af de afbrudte transaktioner.<\/p>\n

En simpel gentagelse af fejlede transaktioner er ikke tilstr\u00e6kkelig til at genoprette. <\/p>\n

Eksempel. Brugeren har 500$ p\u00e5 sin konto, og brugeren beslutter at h\u00e6ve dem via en pengeautomat. Der udf\u00f8res to transaktioner. Den f\u00f8rste l\u00e6ser saldoen, og hvis der er tilstr\u00e6kkelige midler p\u00e5 kontoen, udbetales pengene til brugeren. Den anden fratr\u00e6kker det n\u00f8dvendige bel\u00f8b fra saldoen. Antag, at systemet fejler, og den f\u00f8rste operation ikke blev udf\u00f8rt, men den anden blev udf\u00f8rt. I dette tilf\u00e6lde kan vi ikke udbetale penge til brugeren igen uden at bringe systemet tilbage til sin oprindelige tilstand med en positiv saldo.<\/i><\/p>\n

Isoleringsniveauer<\/h2>\n

<\/p>\n

L\u00e6se fast data (Read Committed)<\/h4>\n

\nProblemet med beskidt l\u00e6sning (Dirty Read) er, at en transaktion kan l\u00e6se et mellemresultat fra en anden transaktion.<\/p>\n

Eksempel. Startsaldoen er 0$. T1 tilf\u00f8jer 50$ til saldoen. T2 l\u00e6ser saldoen (50$). T1 annullerer \u00e6ndringerne og afsluttes. T2 forts\u00e6tter med at udf\u00f8re og har falske oplysninger om saldoen.<\/i><\/p>\n

L\u00f8sningen er at anvende l\u00e6se fast data (Read Committed), som forhindrer l\u00e6sning af data \u00e6ndret af en transaktion. Hvis transaktion A \u00e6ndrer en bestemt datam\u00e6ngde, m\u00e5 transaktion B vente p\u00e5, at transaktion A afsluttes, f\u00f8r den kan f\u00e5 adgang til disse data.<\/p>\n

Gentagen l\u00e6sning (Repeatable Read)<\/h4>\n

\nProblemet med tabte \u00e6ndringer (Lost Updates). T1 gemmer \u00e6ndringer oven p\u00e5 \u00e6ndringer fra T2.<\/p>\n

Eksempel. Startsaldoen er 0$, og to transaktioner fors\u00f8ger samtidigt at tilf\u00f8je til saldoen. T1 og T2 l\u00e6ser saldoen som 0$. T2 tilf\u00f8jer 200$ til 0$ og gemmer resultatet. T1 tilf\u00f8jer 100$ til 0$ og gemmer resultatet. Det endelige resultat er 100$ i stedet for 300$.<\/i><\/p>\n

Problemet med ikke-repetabel l\u00e6sning (Unrepeatable read). Gentagen l\u00e6sning af de samme data giver forskellige v\u00e6rdier.<\/p>\n

Eksempel. T1 l\u00e6ser saldoen som 0$. Derefter tilf\u00f8jer T2 50$ til saldoen og afsluttes. T1 l\u00e6ser dataene igen og opdager en uoverensstemmelse med det tidligere resultat.<\/i><\/p>\n

Gentagen l\u00e6sning (Repeatable Read) garanterer, at gentagen l\u00e6sning returnerer det samme resultat. Data l\u00e6st af \u00e9n transaktion m\u00e5 ikke \u00e6ndres af andre, indtil transaktionen er afsluttet. Hvis transaktion A har l\u00e6st en bestemt datam\u00e6ngde, m\u00e5 transaktion B vente p\u00e5, at transaktion A afsluttes, f\u00f8r den kan f\u00e5 adgang til disse data.<\/p>\n

Ordnet l\u00e6sning (Serializable)<\/h4>\n

\nProblemet med phantoml\u00e6sning (Phantom Reads). To foresp\u00f8rgsler, der v\u00e6lger data baseret p\u00e5 et bestemt kriterium, returnerer forskellige v\u00e6rdier.<\/p>\n

Eksempel. T1 foresp\u00f8rger antal brugere, hvis balance er over 0$ men under 100$. T2 tr\u00e6kker 1$ fra en bruger med en balance p\u00e5 101$. T1 udf\u00f8rer foresp\u00f8rgslen igen.<\/i><\/p>\n

Ordnet l\u00e6sning (Serializable). Transaktioner udf\u00f8res som fuldst\u00e6ndig sekventielle. Det er forbudt at opdatere og tilf\u00f8je poster, der falder ind under foresp\u00f8rgselsbetingelserne. Hvis transaktion A har forespurgt data fra hele tabellen, s\u00e5 fryses tabellen helt for andre transaktioner, indtil transaktion A er afsluttet.<\/p>\n

Planl\u00e6gger (Scheduler)<\/h2>\n

<\/p>\n

Fastl\u00e6gger r\u00e6kkef\u00f8lgen af operationer, der skal udf\u00f8res ved parallelt k\u00f8rende transaktioner<\/h4>\n

\nSikrer det angivne niveau af isolering. Hvis resultatet af operationer ikke afh\u00e6nger af deres r\u00e6kkef\u00f8lge, er s\u00e5danne operationer kommutative (Permutable). L\u00e6seoperationer og operationer p\u00e5 forskellige data er kommutative. L\u00e6se-skriv og skrive-skriv operationer er ikke kommutative. Planl\u00e6ggerens opgave er at vekselere operationer udf\u00f8rt af parallelle transaktioner, s\u00e5 resultatet er \u00e6kvivalent med sekventiel udf\u00f8relse af transaktionerne.<\/p>\n

Kontrolmekanismer for parallelle opgaver (Concurrency Control)<\/h2>\n

<\/p>\n

Optimistisk baseret p\u00e5 opdagelse og l\u00f8sning af konflikter, pessimistisk p\u00e5 at forhindre opst\u00e5en af konflikter<\/h4>\n

\nVed den optimistiske tilgang f\u00e5r flere brugere adgang til kopier af dataene. Den f\u00f8rste, der afslutter redigeringen, gemmer \u00e6ndringerne, mens de andre skal fusionere \u00e6ndringerne. Den optimistiske algoritme tillader en konflikt at opst\u00e5, men systemet skal kunne genoprette sig efter konflikten.<\/p>\n

Ved den pessimistiske tilgang hindrer den f\u00f8rste bruger, der f\u00e5r fat i dataene, de andre i at f\u00e5 adgang til dem. Hvis konflikter er sj\u00e6ldne, kan det v\u00e6re fornuftigt at v\u00e6lge en optimistisk strategi, da den muligg\u00f8r et h\u00f8jere niveau af parallelisme.<\/p>\n

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

<\/p>\n

Hvis \u00e9n transaktion har l\u00e5st dataene, skal de \u00f8vrige transaktioner vente p\u00e5, at aft l\u00e5sningen bliver oph\u00e6vet.<\/h4>\n

\nEn blok kan p\u00e5l\u00e6gges en database, tabel, r\u00e6kke eller attribut. En delt l\u00e5s (Shared Lock) kan p\u00e5l\u00e6gges de samme data af flere transaktioner, hvilket tillader alle transaktioner (herunder den p\u00e5lagte) at l\u00e6se, men forbyder \u00e6ndringer og eksklusive l\u00e5sninger. En eksklusiv l\u00e5s (Exclusive Lock) kan kun p\u00e5l\u00e6gges af \u00e9n transaktion, hvilket tillader alle handlinger af den p\u00e5lagte transaktion og forbyder alle handlinger af de resterende.<\/p>\n

En situation, hvor transaktioner befinder sig i en ventetilstand, der varer uendeligt, kaldes en deadlock.<\/h4>\n

\nEksempel. Den f\u00f8rste transaktion venter p\u00e5 frigivelse af data, der er l\u00e5st af den anden, mens den anden venter p\u00e5 frigivelse af data l\u00e5st af den f\u00f8rste.<\/i><\/p>\n

Den optimistiske l\u00f8sning p\u00e5 deadlock-problemet tillader, at deadlock opst\u00e5r, men genopretter derefter systemet ved at tilbagef\u00f8re en af transaktionerne, der er involveret i deadlocken.<\/h4>\n

\nMed j\u00e6vne mellemrum foretages der s\u00f8gning efter deadlocks. En af metoderne til opdagelse er tidsbaseret, hvilket vil sige, at man betragter det som en deadlock, hvis en transaktion k\u00f8rer for l\u00e6nge. N\u00e5r en deadlock findes, tilbagef\u00f8res en af transaktionerne, hvilket giver mulighed for, at andre transaktioner involveret i deadlocken kan afsluttes. Valget af offer kan baseres p\u00e5 transaktionernes omkostninger eller deres anciennitet (Wait-Die og Wound-Wait skemaer). <\/p>\n

Hver transaktion T<\/b> tildeles et tidsstempel TS<\/b> som indeholder tidspunktet for, hvorn\u00e5r transaktionen blev p\u00e5begyndt.<\/p>\n

Wait-Die. <\/p>\n

Hvis TS(Ti)<\/b> < TS(Tj)<\/b>, s\u00e5 Ti<\/b> venter, ellers Ti<\/b> tilbagef\u00f8res og starter forfra med det samme tidsstempel.<\/u><\/p>\n

Hvis en yngre transaktion har l\u00e5st en ressource, og en \u00e6ldre anmoder om den samme ressource, s\u00e5 m\u00e5 den \u00e6ldre transaktion vente. Hvis en \u00e6ldre transaktion har l\u00e5st ressourcen, s\u00e5 vil den yngre transaktion, der anmoder om denne ressource, blive tilbagef\u00f8rt.<\/p>\n

Wound-Wait. <\/p>\n

Hvis TS(Ti)<\/b> < TS(Tj)<\/b>, s\u00e5 Tj<\/b> bliver tilbagef\u00f8rt og starter forfra med det samme tidsstempel, ellers Ti<\/b> venter.<\/u><\/p>\n

Hvis en yngre transaktion har taget kontrol over en ressource, og en \u00e6ldre transaktion anmoder om den samme ressource, vil den yngre transaktion blive tilbagekaldt. Hvis en \u00e6ldre transaktion har taget kontrol over ressourcen, skal den yngre transaktion, der anmoder om den p\u00e5g\u00e6ldende ressource, vente. Valget af offer baseret p\u00e5 alder forhindrer optr\u00e6den af deadlocks, men tilbagekalder transaktioner, der ikke er i en tilstand af deadlock. Problemet er, at transaktioner kan blive tilbagekaldt flere gange, da en \u00e6ldre transaktion kan holde ressourcen i lang tid.<\/p>\n

En pessimistisk l\u00f8sning p\u00e5 deadlock-problemet tillader ikke transaktionen at begynde udf\u00f8relsen, hvis der er risiko for at opn\u00e5 en deadlock.<\/h4>\n

\nFor at opdage deadlocks opbygges en graf (ventningsgraf, wait-for-graph), hvor noderne repr\u00e6senterer transaktioner, og kanterne er rettet fra transaktioner, der venter p\u00e5 frigivelse af data, til transaktioner, der har taget kontrol over disse data. Det antages, at der har v\u00e6ret en deadlock, hvis grafen har en cyklus. Opbygning af ventningsgrafen, is\u00e6r i distribuerede databaser, er en kostbar procedure.<\/p>\n

To-fase l\u00e5sning - forhindring af deadlocks ved at tage kontrol over alle ressourcer, der bruges af transaktionen i starten af transaktionen og frigive dem i slutningen.<\/h4>\n

\nAlle l\u00e5seoperationer skal finde sted f\u00f8r den f\u00f8rste frigivelsesoperation. Det har to faser - v\u00e6kstfasen, hvor l\u00e5seakkumuleres, og krympningsfasen, hvor l\u00e5se frigives. Hvis det ikke er muligt at tage kontrol over en af ressourcerne, starter transaktionen forfra. Det er muligt, at en transaktion ikke kan tage kontrol over de n\u00f8dvendige ressourcer, hvis flere transaktioner konkurrerer om de samme ressourcer.<\/p>\n

To-fase commit sikrer udf\u00f8relsen af commit p\u00e5 alle replikaer af databasen.<\/h4>\n

\nHver database indf\u00f8rer oplysninger om de data, der vil blive \u00e6ndret i en log og svarer til koordinatoren med OK (Voting Phase). Efter at alle har svaret OK, sender koordinatoren et signal, der forpligter alle til at gennemf\u00f8re commit. Efter commit server<\/a> svarer de med OK; hvis blot \u00e9n ikke svarer med OK, sender koordinatoren et signal om at annullere \u00e6ndringerne til alle servere (Completion Phase).<\/p>\n

Metoden med tidsstempler.<\/h2>\n

<\/p>\n

En \u00e6ldre transaktion bliver tilbagekaldt, n\u00e5r den fors\u00f8ger at f\u00e5 adgang til data, der er involveret i en yngre transaktion.<\/h4>\n

\nHver transaktion tildeles et tidsstempel TS<\/b> som svarer til det tidspunkt, hvor den bliver udf\u00f8rt. Hvis Ti<\/b> \u00e6ldre Tj<\/b>, s\u00e5 TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

N\u00e5r en transaktion rulles tilbage, tildeles den et nyt tidsstempel. Hvert datablob Q<\/b> involveret i transaktionen markeres med to timestamps. W-TS(Q)<\/b> \u2014 tidsstemplet for den yngste transaktion, der har fuldf\u00f8rt en skrivning til Q<\/b>. R-TS(Q)<\/b> \u2014 tidsstemplet for den yngste transaktion, der har udf\u00f8rt en l\u00e6seskrivning til Q<\/b>.<\/p>\n

N\u00e5r transaktionen T<\/b> anmoder om at l\u00e6se data Q<\/b> er der to muligheder.<\/p>\n

Hvis TS(T)<\/b> < W-TS(Q)<\/b>, det vil sige at dataene er blevet opdateret af en yngre transaktion, s\u00e5 transaktionen T<\/b> rulles tilbage.<\/u><\/p>\n

Hvis TS(T)<\/b> \u2265 W-TS(Q)<\/b>, s\u00e5 udf\u00f8res l\u00e6sningen og R-TS(Q)<\/b> bliver MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

N\u00e5r transaktionen T<\/b> anmoder om at \u00e6ndre data Q<\/b> er der to muligheder. <\/p>\n

Hvis TS(T)<\/b> < R-TS(Q)<\/b>, det vil sige at dataene allerede er blevet l\u00e6st af en yngre transaktion, og hvis der foretages en \u00e6ndring, vil det skabe en konfliktsituation. Transaktionen T<\/b> rulles tilbage. <\/u><\/p>\n

Hvis TS(T)<\/b> < W-TS(Q)<\/b>, det vil sige at transaktionen fors\u00f8ger at overskrive en nyere v\u00e6rdi, transaktionen T rulles tilbage. I alle andre tilf\u00e6lde gennemf\u00f8res \u00e6ndringen og W-TS(Q)<\/b> bliver lig med TS(T)<\/b>.<\/u><\/p>\n

Der er ikke behov for dyre ventegrafer. \u00c6ldre transaktioner er afh\u00e6ngige af nyere, s\u00e5 der er ingen cyklusser i ventegrafen. Der er ingen deadlocks, da transaktionerne ikke venter, men rulles tilbage med det samme. Kaskade tilbageslag er mulige. Hvis Ti<\/b> er blevet rullet tilbage, og Tj<\/b> har l\u00e6st de data, som den \u00e6ndrede Ti<\/b>, s\u00e5 Tj<\/b> skal ogs\u00e5 rulles tilbage. Hvis dette samtidig Tj<\/b> allerede er blevet bekr\u00e6ftet, vil det kr\u00e6nke princippet om konsistens.<\/p>\n

En l\u00f8sning p\u00e5 kaskade tilbageslag. Transaktionen udf\u00f8rer alle skriveoperationer til sidst, og de \u00f8vrige transaktioner skal vente p\u00e5, at denne operation er afsluttet. Transaktionerne venter p\u00e5 en bekr\u00e6ftelse f\u00f8r l\u00e6sning.<\/p>\n

Thomas write rule \u2014 en variation af metoden med tidsstempler, hvor data opdateret af en yngre transaktion ikke m\u00e5 overskrives af en \u00e6ldre<\/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 og deres kontrolmekanismer | ProHoster","description":"Transaktioner En transaktion er en sekvens af operationer over data, som har en begyndelse og en slutning. En transaktion er sekventiel udf\u00f8relse af l\u00e6se- og skriveoperationer.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransaktion T<\/b> anmoder om at \u00e6ndre data Q<\/b>. Hvis TS(T)<\/b> < W-TS(Q)<\/b>, det vil sige at transaktionen fors\u00f8ger at overskrive en nyere v\u00e6rdi, transaktionen T rulles ikke tilbage som i metoden med tidsstempler.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"