{"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\/nl\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transacties en de mechanismen voor hun controle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transacties<\/h2>\n

<\/p>\n

Een transactie is een reeks bewerkingen op gegevens met een begin en een einde.<\/h4>\n

\nEen transactie is de opeenvolgende uitvoering van lees- en schrijfoperaties. Het einde van een transactie kan zijn ofwel het opslaan van wijzigingen (commit) of het annuleren van wijzigingen (rollback). In het geval van databases is een transactie een aantal verzoeken die als \u00e9\u00e9n verzoek worden beschouwd.<\/p>\n

Transacties moeten voldoen aan de ACID-eisen.<\/h4>\n

\nAtomiciteit. Een transactie wordt ofwel volledig uitgevoerd of helemaal niet.<\/p>\n

Consistentie. Bij het be\u00ebindigen van een transactie mogen de opgelegde beperkingen op de gegevens (bijvoorbeeld constraints in de database) niet worden geschonden. Consistentie houdt in dat het systeem van de ene correcte staat naar een andere correcte staat wordt overgebracht.<\/p>\n

Isolatie. Gelijktijdig uitgevoerde transacties mogen elkaar niet be\u00efnvloeden, bijvoorbeeld door gegevens te wijzigen die door een andere transactie worden gebruikt. Het resultaat van gelijktijdige transacties moet zijn alsof de transacties sequenteel worden uitgevoerd.<\/p>\n

Duurzaamheid. Na een commit mogen wijzigingen niet verloren gaan.
\n<\/a><\/noindex><\/p>\n

Transactie-logboek<\/h2>\n

<\/p>\n

Het logboek slaat de wijzigingen op die zijn uitgevoerd door de transacties en zorgt voor de atomiciteit en duurzaamheid van de gegevens in geval van een systeemfout.<\/h4>\n

\nHet logboek bevat de waarden die de gegevens hadden voordat en nadat ze door de transactie zijn gewijzigd. De Write-ahead log-strategie verplicht tot het toevoegen van een registratie van de vorige waarden aan het logboek voordat de transactie begint, en van de eindwaarden nadat de transactie is voltooid. In het geval van een onverwachte stop leest de database het logboek in omgekeerde volgorde en annuleert de wijzigingen die door de transacties zijn aangebracht. Wanneer de database een onderbroken transactie tegenkomt, voert ze deze uit en voegt de wijzigingen toe aan het logboek. In de staat op het moment van de storing leest de database het logboek in rechte volgorde en herstelt de wijzigingen die door de transacties zijn aangebracht. Op deze manier wordt de duurzaamheid van transacties die al zijn gecommit en de atomiciteit van de onderbroken transactie behouden.<\/p>\n

Een eenvoudige herhaalde uitvoering van foutieve transacties is onvoldoende voor herstel. <\/p>\n

Voorbeeld. De gebruiker heeft $500 op zijn rekening en besluit deze op te nemen via een geldautomaat. Er worden twee transacties uitgevoerd. De eerste leest de saldo en als er voldoende middelen op de rekening staan, geeft het geld aan de gebruiker. De tweede trekt het benodigde bedrag van het saldo af. Stel dat er een systeemfout optreedt en de eerste operatie niet is uitgevoerd, terwijl de tweede is uitgevoerd. In dit geval kunnen we het geld niet opnieuw aan de gebruiker geven zonder het systeem terug te brengen naar de oorspronkelijke staat met een positief saldo.<\/i><\/p>\n

Isolatieniveaus<\/h2>\n

<\/p>\n

Gecommitteerde Lezingen (Read Committed)<\/h4>\n

\nHet probleem van onbetrouwbaar lezen (Dirty Read) bestaat uit het feit dat een transactie een tussenresultaat van een andere transactie kan lezen.<\/p>\n

Voorbeeld. Aanvankelijk saldo is $0. T1 voegt $50 toe aan het saldo. T2 leest het saldo (dat $50 is). T1 herroept de wijzigingen en voltooit. T2 gaat door met de uitvoering met onjuiste gegevens over het saldo.<\/i><\/p>\n

De oplossing is gecommitteerde lezingen (Read Committed) die het lezen van gegevens die door een transactie zijn gewijzigd, verbiedt. Als transactie A een bepaalde set gegevens wijzigt, moet transactie B wachten op de voltooiing van transactie A bij het opvragen van deze gegevens.<\/p>\n

Herhaalbare Lezing (Repeatable Read)<\/h4>\n

\nHet probleem van verloren updates (Lost Updates). T1 slaat wijzigingen op bovenop de wijzigingen van T2.<\/p>\n

Voorbeeld. Aanvankelijk saldo is $0 en twee transacties voegen gelijktijdig geld toe aan het saldo. T1 en T2 lezen het saldo dat gelijk is aan $0. Vervolgens voegt T2 $200 toe aan $0 en slaat het resultaat op. T1 voegt $100 toe aan $0 en slaat het resultaat op. Het eindresultaat is $100 in plaats van $300.<\/i><\/p>\n

Het probleem van onherhaalbare lezen (Unrepeatable Read). Het opnieuw lezen van dezelfde gegevens retourneert verschillende waarden.<\/p>\n

Voorbeeld. T1 leest het saldo dat gelijk is aan $0. Vervolgens voegt T2 $50 toe aan het saldo en voltooit. T1 leest de gegevens opnieuw en ontdekt een discrepantie met het eerdere resultaat.<\/i><\/p>\n

Herhaalbare Lezing (Repeatable Read) garandeert dat een opnieuw gelezen waarde hetzelfde resultaat oplevert. Gegevens die door een transactie zijn gelezen, mogen in een andere transactie niet worden gewijzigd totdat die transactie is voltooid. Als transactie A een bepaalde set gegevens heeft gelezen, moet transactie B wachten op de voltooiing van transactie A bij het opvragen van deze gegevens.<\/p>\n

Geordende Lezing (Serializable)<\/h4>\n

\nHet probleem van phantom reads. Twee queries die gegevens op basis van een bepaalde voorwaarde selecteren, geven verschillende waarden terug.<\/p>\n

Voorbeeld. T1 vraagt het aantal gebruikers wiens saldo meer dan 0$ maar minder dan 100$ is. T2 trekt 1$ af van de gebruiker met een saldo van 101$. T1 voert de query opnieuw uit.<\/i><\/p>\n

Geordende lezing (Serializable). Transacties worden uitgevoerd als geheel sequentieel. Het is verboden om records bij te werken of toe te voegen die onder de voorwaarden van de query vallen. Als transactie A gegevens van de hele tabel heeft opgevraagd, wordt de tabel voor andere transacties bevroren totdat transactie A is voltooid.<\/p>\n

Scheduler (Scheduler)<\/h2>\n

<\/p>\n

Stelt de volgorde vast waarin operaties moeten worden uitgevoerd bij gelijktijdige transacties.<\/h4>\n

\nZorgt voor het vastgestelde niveau van isolatie. Als het resultaat van de uitvoering van operaties niet afhankelijk is van hun volgorde, zijn dergelijke operaties commutatief (Permutable). Lezen en operaties op verschillende gegevens zijn commutatief. Lezen-schrijven en schrijven-schrijven operaties zijn niet commutatief. De taak van de scheduler is om operaties van gelijktijdige transacties zodanig af te wisselen dat het resultaat equivalente is aan sequenti\u00eble uitvoering van transacties.<\/p>\n

Mechanismen voor controle van gelijktijdige taken (Concurrency Control)<\/h2>\n

<\/p>\n

Optimistisch is gebaseerd op het detecteren en oplossen van conflicten, pessimistisch op het voorkomen van conflicten.<\/h4>\n

\nBij de optimistische benadering krijgen meerdere gebruikers kopie\u00ebn van de gegevens. De eerste die het bewerken voltooit, slaat de wijzigingen op, terwijl de anderen hun wijzigingen moeten samenvoegen. Het optimistische algoritme staat toe dat een conflict zich voordoet, maar het systeem moet zich na het conflict herstellen.<\/p>\n

Bij de pessimistische benadering verhindert de eerste gebruiker die de gegevens heeft gepakt dat anderen de gegevens verkrijgen. Als conflicten zeldzaam zijn, is het verstandig om de optimistische strategie te kiezen, aangezien deze een hoger niveau van parallelisme biedt.<\/p>\n

Vergrendeling (Locking)<\/h2>\n

<\/p>\n

Als \u00e9\u00e9n transactie de gegevens heeft vergrendeld, moeten andere transacties wachten op de ontgrendeling wanneer ze toegang tot de gegevens willen.<\/h4>\n

\nEen blok kan worden opgelegd aan een database, tabel, rij of attribuut. Een gedeelde vergrendeling (Shared Lock) kan op dezelfde gegevens worden gelegd door meerdere transacties, waardoor alle transacties (inclusief de vergrendeling) kunnen lezen, maar wijzigingen en monopolvergrendeling worden verboden. Een exclusieve vergrendeling (Exclusive Lock) kan slechts door \u00e9\u00e9n transactie worden opgelegd, die alle acties van die transactie toestaat en alle acties van andere transacties verbiedt.<\/p>\n

Een deadlock is een situatie waarin transacties in een eindeloze wachttijd terechtkomen.<\/h4>\n

\nVoorbeeld. De eerste transactie wacht op de vrijgave van gegevens die door de tweede zijn vergrendeld, terwijl de tweede wacht op de vrijgave van gegevens die door de eerste zijn vergrendeld.<\/i><\/p>\n

Een optimistische oplossing voor het deadlock-probleem maakt het mogelijk dat deadlocks optreden, maar herstelt het systeem door een van de transacties die bij de deadlock betrokken zijn terug te draaien.<\/h4>\n

\nMet een bepaalde frequentie wordt gezocht naar deadlocks. Een van de manieren om ze te detecteren is tijdgebonden, dat wil zeggen dat men aanneemt dat er een deadlock heeft plaatsgevonden als de transactie te lang bezig is. Wanneer een deadlock is gevonden, wordt een van de transacties teruggedraaid, waardoor andere transacties die bij de deadlock betrokken zijn, kunnen worden voltooid. De keuze voor het slachtoffer kan gebaseerd zijn op de kosten van de transacties of hun ouderdom (Wait-Die en Wound-wait schema's). <\/p>\n

Elke transactie T<\/b> krijgt een tijdstempel TS<\/b> die de starttijd van de transactie bevat.<\/p>\n

Wait-Die. <\/p>\n

Als TS(Ti)<\/b> < TS(Tj)<\/b>, dan Ti<\/b> wacht, anders Ti<\/b> wordt teruggedraaid en begint opnieuw met dezelfde tijdstempel.<\/u><\/p>\n

Als de jongere transactie de bron heeft vergrendeld en de oudere dezelfde bron aanvraagt, mag de oudere transactie wachten. Als de oudere transactie de bron heeft vergrendeld, wordt de jongere transactie die deze bron aanvraagt teruggedraaid.<\/p>\n

Wound-wait. <\/p>\n

Als TS(Ti)<\/b> < TS(Tj)<\/b>, dan Tj<\/b> wordt teruggedraaid en begint opnieuw met dezelfde tijdstempel, anders Ti<\/b> wacht.<\/u><\/p>\n

Als een jongere transactie een resource heeft vastgelegd en een oudere transactie om diezelfde resource vraagt, zal de jongere transactie worden teruggedraaid. Als een oudere transactie de resource heeft vastgelegd, mag de jongere transactie die deze resource aanvraagt wachten. De keuze van een slachtoffer op basis van ouderdom voorkomt het ontstaan van deadlocks, maar draait transacties terug die zich niet in een deadlock bevinden. Het probleem is dat transacties meerdere keren kunnen worden teruggedraaid, omdat een oudere transactie de resource lange tijd kan vasthouden.<\/p>\n

Een pessimistische oplossing voor het deadlock-probleem staat niet toe dat een transactie begint met uitvoeren als er risico op een deadlock is.<\/h4>\n

\nOm deadlocks te detecteren, wordt er een grafiek (wachtgrafiek, wait-for-graph) opgebouwd, waarvan de knooppunten transacties zijn, en de randen zijn gericht van transacties die wachten op het vrijgeven van gegevens naar de transacties die deze gegevens hebben vastgelegd. Er wordt aangenomen dat er een deadlock is opgetreden als de grafiek cycli bevat. Het opbouwen van de wachtgrafiek is vooral in gedistribueerde databases een kostbare procedure.<\/p>\n

Twee-fasige locking is een methode om deadlocks te voorkomen door alle resources die door de transactie worden gebruikt in het begin van de transactie vast te leggen en deze aan het einde vrij te geven.<\/h4>\n

\nAlle blokkeringen moeten voorafgaan aan de eerste ontgrendeling. Dit heeft twee fasen: de Growing Phase, waarin de vastleggingen worden verzameld, en de Shrinking Phase, waarin de vastleggingen worden vrijgegeven. Als het niet mogelijk is om een van de resources vast te leggen, begint de transactie opnieuw. Het is mogelijk dat een transactie de benodigde resources niet kan vastleggen, bijvoorbeeld wanneer meerdere transacties strijden om dezelfde resources.<\/p>\n

Twee-fasige commit zorgt ervoor dat de commit op alle replica's van de database wordt uitgevoerd.<\/h4>\n

\nElke database registreert informatie over de gegevens die zullen worden gewijzigd in een logboek en bevestigt dit aan de co\u00f6rdinator (Voting Phase). Nadat iedereen 'OK' heeft gezegd, verstuurt de co\u00f6rdinator een signaal dat iedereen verplicht om de commit uit te voeren. Na de commit de server<\/a> bevestigen ze 'OK'; als iemand niet 'OK' heeft geantwoord, stuurt de co\u00f6rdinator een annuleringssignaal naar alle servers (Completion Phase).<\/p>\n

De methode van tijdstempels<\/h2>\n

<\/p>\n

Een oudere transactie wordt teruggedraaid bij het proberen toegang te krijgen tot gegevens die door een jongere transactie zijn gebruikt.<\/h4>\n

\nElke transactie krijgt een tijdstempel toegewezen TS<\/b> die overeenkomt met het tijdstip van uitvoering. Als Ti<\/b> ouder is Tj<\/b>, dan TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Wanneer een transactie wordt teruggedraaid, krijgt deze een nieuwe tijdstempel toegewezen. Elk gegevensobject Q<\/b> betrokken bij de transactie wordt gemarkeerd met twee tijdstempels. W-TS(Q)<\/b> \u2014 tijdstempel van de jongste transactie die succesvol een schrijfoperatie heeft uitgevoerd op Q<\/b>. R-TS(Q)<\/b> \u2014 tijdstempel van de jongste transactie die een leesoperatie heeft uitgevoerd op Q<\/b>.<\/p>\n

Wanneer de transactie T<\/b> gegevens leest, Q<\/b> zijn er twee mogelijkheden.<\/p>\n

Als TS(T)<\/b> < W-TS(Q)<\/b>, dat wil zeggen dat de gegevens zijn bijgewerkt door een jongere transactie, dan wordt de transactie T<\/b> teruggedraaid.<\/u><\/p>\n

Als TS(T)<\/b> >= W-TS(Q)<\/b>, dan wordt de lezing uitgevoerd en R-TS(Q)<\/b> het cre\u00ebren van services die het werken met multi-cloud vergemakkelijken. VMware is een van de bedrijven die zich in deze richting ontwikkelt. MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Wanneer de transactie T<\/b> verzoekt om wijziging van gegevens Q<\/b> zijn er twee mogelijkheden. <\/p>\n

Als TS(T)<\/b> < R-TS(Q)<\/b>, dat wil zeggen dat de gegevens al zijn gelezen door een jongere transactie en als er een wijziging plaatsvindt, er een conflict zal ontstaan. De transactie T<\/b> teruggedraaid. <\/u><\/p>\n

Als TS(T)<\/b> < W-TS(Q)<\/b>, dat wil zeggen dat de transactie probeert een recenter waarde te overschrijven, wordt transactie T teruggedraaid. In andere gevallen wordt de wijziging uitgevoerd en W-TS(Q)<\/b> wordt gelijk aan TS(T)<\/b>.<\/u><\/p>\n

Er is geen dure opbouw van een wachtgraf nodig. Oudere transacties zijn afhankelijk van nieuwere, waardoor er geen cycli in het wachtgraf zijn. Er zijn geen deadlocks, omdat transacties niet wachten, maar direct teruggedraaid worden. Cascaderende terugdraaien zijn mogelijk. Als Ti<\/b> is teruggedraaid, en Tj<\/b> heeft gegevens gelezen die gewijzigd zijn, Ti<\/b>, dan Tj<\/b> moet ook teruggedraaid worden. Als dit het geval is Tj<\/b> al is gecommit, zal er een inbreuk op het stabiliteitsprincipe ontstaan.<\/p>\n

Een van de oplossingen voor cascaderende terugdraaien. De transactie voert alle schrijfoperaties aan het einde uit, en andere transacties moeten wachten op de voltooiing van deze operatie. Transacties wachten op de commit voordat ze lezen.<\/p>\n

Thomas write rule \u2014 variatie van de tijdstempelmethoden waarbij gegevens die zijn bijgewerkt door een jongere transactie niet door een oudere mogen worden overschreven.<\/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\udd47Transacties en hun controlemechanismen | ProHoster","description":"Transacties Een transactie is een reeks bewerkingen op gegevens met een begin en een einde. Een transactie is een opeenvolgende uitvoering van lees- en schrijfoperaties.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nDe transactie T<\/b> verzoekt om wijziging van gegevens Q<\/b>. Als TS(T)<\/b> < W-TS(Q)<\/b>, dat wil zeggen dat de transactie probeert een recenter waarde te overschrijven, wordt transactie T niet teruggedraaid zoals in de tijdstempelmethoden.
\n
Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"