{"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\/fr\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transactions et m\u00e9canismes de leur contr\u00f4le","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transactions<\/h2>\n

<\/p>\n

Une transaction est une s\u00e9quence d'op\u00e9rations sur des donn\u00e9es ayant un d\u00e9but et une fin.<\/h4>\n

\nUne transaction est l'ex\u00e9cution s\u00e9quentielle d'op\u00e9rations de lecture et d'\u00e9criture. La fin d'une transaction peut \u00eatre soit la validation des modifications (commit) soit l'annulation des modifications (rollback). Dans le cadre des bases de donn\u00e9es, une transaction est compos\u00e9e de plusieurs requ\u00eates qui sont trait\u00e9es comme une seule.<\/p>\n

Les transactions doivent satisfaire aux propri\u00e9t\u00e9s ACID.<\/h4>\n

\nAtomicit\u00e9. Une transaction est soit enti\u00e8rement r\u00e9alis\u00e9e, soit pas du tout.<\/p>\n

Coh\u00e9rence. \u00c0 la fin d'une transaction, les contraintes impos\u00e9es sur les donn\u00e9es ne doivent pas \u00eatre viol\u00e9es (par exemple, les constraints dans une base de donn\u00e9es). La coh\u00e9rence signifie que le syst\u00e8me passera d'un \u00e9tat correct \u00e0 un autre \u00e9tat correct.<\/p>\n

Isolation. Les transactions ex\u00e9cut\u00e9es en parall\u00e8le ne doivent pas interf\u00e9rer les unes avec les autres, par exemple, ne pas modifier les donn\u00e9es utilis\u00e9es par une autre transaction. Le r\u00e9sultat de l'ex\u00e9cution de transactions parall\u00e8les doit \u00eatre le m\u00eame que si elles avaient \u00e9t\u00e9 ex\u00e9cut\u00e9es s\u00e9quentiellement.<\/p>\n

Durabilit\u00e9. Apr\u00e8s validation, les modifications ne doivent pas \u00eatre perdues.
\n<\/a><\/noindex><\/p>\n

Journal des transactions.<\/h2>\n

<\/p>\n

Le journal conserve les modifications effectu\u00e9es par les transactions, garantissant l'atomicit\u00e9 et la durabilit\u00e9 des donn\u00e9es en cas de d\u00e9faillance du syst\u00e8me.<\/h4>\n

\nLe journal contient les valeurs que les donn\u00e9es avaient avant et apr\u00e8s leur modification par la transaction. La strat\u00e9gie du journal d'\u00e9criture anticip\u00e9e oblige \u00e0 ajouter dans le journal un enregistrement des valeurs pr\u00e9c\u00e9dentes avant le d\u00e9but, et des valeurs finales apr\u00e8s la fin d'une transaction. En cas d'arr\u00eat soudain du syst\u00e8me, la base de donn\u00e9es lit le journal \u00e0 l'envers et annule les modifications effectu\u00e9es par les transactions. En rencontrant une transaction interrompue, la base de donn\u00e9es l'ex\u00e9cute et enregistre ses modifications dans le journal. En \u00e9tant dans l'\u00e9tat au moment de la d\u00e9faillance, la base de donn\u00e9es lit le journal dans l'ordre et r\u00e9tablit les modifications effectu\u00e9es par les transactions. Ainsi, la durabilit\u00e9 des transactions d\u00e9j\u00e0 valid\u00e9es et l'atomicit\u00e9 de la transaction interrompue sont pr\u00e9serv\u00e9es.<\/p>\n

Une simple r\u00e9ex\u00e9cution des transactions erron\u00e9es n'est pas suffisante pour la r\u00e9cup\u00e9ration. <\/p>\n

Exemple. Un utilisateur a un solde de 500$ et d\u00e9cide de retirer cet argent via un distributeur automatique. Deux transactions sont ex\u00e9cut\u00e9es. La premi\u00e8re lit la valeur du solde et, si le solde est suffisant, d\u00e9livre l'argent \u00e0 l'utilisateur. La seconde soustrait le montant du solde. Supposons qu'un dysfonctionnement du syst\u00e8me se produise et que la premi\u00e8re op\u00e9ration n'ait pas \u00e9t\u00e9 ex\u00e9cut\u00e9e, tandis que la seconde l'a \u00e9t\u00e9. Dans ce cas, nous ne pouvons pas red\u00e9livrer de l'argent \u00e0 l'utilisateur sans restaurer le syst\u00e8me \u00e0 son \u00e9tat initial avec un solde positif.<\/i><\/p>\n

Niveaux d'isolement<\/h2>\n

<\/p>\n

Lecture des donn\u00e9es fixes (Read Committed)<\/h4>\n

\nLe probl\u00e8me de la lecture sale (Dirty Read) r\u00e9side dans le fait qu'une transaction peut lire un r\u00e9sultat interm\u00e9diaire provenant d'une autre transaction.<\/p>\n

Exemple. La valeur initiale du solde est de 0$. T1 ajoute 50$ au solde. T2 lit la valeur du solde (50$). T1 annule les modifications et se termine. T2 continue son ex\u00e9cution avec des donn\u00e9es incorrectes sur le solde.<\/i><\/p>\n

La solution est la lecture des donn\u00e9es fixes (Read Committed) qui interdit de lire les donn\u00e9es modifi\u00e9es par une transaction. Si la transaction A a modifi\u00e9 un certain ensemble de donn\u00e9es, alors la transaction B, en essayant d'acc\u00e9der \u00e0 ces donn\u00e9es, doit attendre que la transaction A soit termin\u00e9e.<\/p>\n

Lecture r\u00e9p\u00e9t\u00e9e (Repeatable Read)<\/h4>\n

\nLe probl\u00e8me des mises \u00e0 jour perdues (Lost Updates). T1 enregistre des modifications sur les modifications de T2.<\/p>\n

Exemple. La valeur initiale du solde est de 0$ et deux transactions remplissent simultan\u00e9ment le solde. T1 et T2 lisent un solde \u00e9gal \u00e0 0$. Ensuite, T2 ajoute 200$ \u00e0 0$ et enregistre le r\u00e9sultat. T1 ajoute 100$ \u00e0 0$ et enregistre le r\u00e9sultat. Le r\u00e9sultat final est 100$ au lieu de 300$.<\/i><\/p>\n

Le probl\u00e8me de la lecture non r\u00e9p\u00e9t\u00e9e (Unrepeatable Read). Une nouvelle lecture des m\u00eames donn\u00e9es renvoie des valeurs diff\u00e9rentes.<\/p>\n

Exemple. T1 lit une valeur de solde \u00e9gale \u00e0 0$. Ensuite, T2 ajoute 50$ au solde et se termine. T1 relit les donn\u00e9es et d\u00e9couvre un \u00e9cart avec le r\u00e9sultat pr\u00e9c\u00e9dent.<\/i><\/p>\n

La lecture r\u00e9p\u00e9t\u00e9e (Repeatable Read) garantit qu'une nouvelle lecture renverra le m\u00eame r\u00e9sultat. Les donn\u00e9es lues par une transaction ne peuvent pas \u00eatre modifi\u00e9es par d'autres jusqu'\u00e0 la fin de la transaction. Si la transaction A a lu un certain ensemble de donn\u00e9es, alors la transaction B, en essayant d'acc\u00e9der \u00e0 ces donn\u00e9es, doit attendre que la transaction A soit termin\u00e9e.<\/p>\n

Lecture ordonn\u00e9e (Serializable)<\/h4>\n

\nProbl\u00e8me de lecture fant\u00f4me (Phantom Reads). Deux requ\u00eates s\u00e9lectionnant des donn\u00e9es sur une certaine condition retournent des valeurs diff\u00e9rentes.<\/p>\n

Exemple. T1 demande le nombre total d'utilisateurs dont le solde est sup\u00e9rieur \u00e0 0 $ mais inf\u00e9rieur \u00e0 100 $. T2 soustrait 1 $ \u00e0 un utilisateur avec un solde de 101 $. T1 ex\u00e9cute \u00e0 nouveau la requ\u00eate.<\/i><\/p>\n

Lecture ordonn\u00e9e (Serializable). Les transactions s'ex\u00e9cutent comme enti\u00e8rement s\u00e9quentielles. Il est interdit de mettre \u00e0 jour ou d'ajouter des enregistrements correspondant aux conditions de la requ\u00eate. Si la transaction A demande des donn\u00e9es de toute la table, celle-ci est enti\u00e8rement gel\u00e9e pour les autres transactions jusqu'\u00e0 ce que la transaction A soit termin\u00e9e.<\/p>\n

Planificateur (Scheduler)<\/h2>\n

<\/p>\n

\u00c9tablit l'ordre dans lequel les op\u00e9rations doivent \u00eatre ex\u00e9cut\u00e9es lors de transactions simultan\u00e9es.<\/h4>\n

\nAssure un niveau d'isolation sp\u00e9cifi\u00e9. Si le r\u00e9sultat de l'ex\u00e9cution des op\u00e9rations ne d\u00e9pend pas de leur ordre, alors ces op\u00e9rations sont commutatives (Permutable). Les op\u00e9rations de lecture et les op\u00e9rations sur des donn\u00e9es diff\u00e9rentes sont commutatives. Les op\u00e9rations de lecture-\u00e9criture et les \u00e9critures-\u00e9critures ne sont pas commutatives. La t\u00e2che du planificateur est d'alterner les op\u00e9rations ex\u00e9cut\u00e9es par des transactions parall\u00e8les de mani\u00e8re \u00e0 ce que le r\u00e9sultat soit \u00e9quivalent \u00e0 une ex\u00e9cution s\u00e9quentielle des transactions.<\/p>\n

M\u00e9canismes de contr\u00f4le de la concurrence (Concurrency Control)<\/h2>\n

<\/p>\n

Optimiste bas\u00e9 sur la d\u00e9tection et la r\u00e9solution de conflits, pessimiste sur la pr\u00e9vention de l'apparition de conflits.<\/h4>\n

\nAvec l'approche optimiste, plusieurs utilisateurs re\u00e7oivent des copies des donn\u00e9es. Le premier \u00e0 terminer l'\u00e9dition sauvegarde ses modifications, les autres doivent fusionner les changements. L'algorithme optimiste permet un conflit, mais le syst\u00e8me doit se r\u00e9tablir apr\u00e8s le conflit.<\/p>\n

Avec l'approche pessimiste, le premier utilisateur \u00e0 capturer les donn\u00e9es emp\u00eache les autres d'acc\u00e9der aux donn\u00e9es. Si les conflits sont rares, il est raisonnable de choisir une strat\u00e9gie optimiste, car elle offre un niveau de parall\u00e9lisme plus \u00e9lev\u00e9.<\/p>\n

Verrouillage (Locking)<\/h2>\n

<\/p>\n

Si une transaction a verrouill\u00e9 des donn\u00e9es, les autres transactions doivent attendre le d\u00e9verrouillage lorsqu'elles acc\u00e8dent aux donn\u00e9es.<\/h4>\n

\nUn bloc peut s'appliquer \u00e0 une base de donn\u00e9es, une table, une ligne ou un attribut. Un verrou partag\u00e9 (Shared Lock) peut \u00eatre impos\u00e9 sur certaines donn\u00e9es par plusieurs transactions, permettant \u00e0 toutes les transactions (y compris celle qui l'a appliqu\u00e9) de lire, tout en interdisant les modifications et le verrouillage exclusif. Un verrou exclusif (Exclusive Lock) ne peut \u00eatre impos\u00e9 que par une seule transaction, autorisant toutes les actions de la transaction ayant appliqu\u00e9 le verrou, tout en interdisant les actions des autres.<\/p>\n

Un interblocage est une situation o\u00f9 les transactions se retrouvent en attente ind\u00e9finiment.<\/h4>\n

\nExemple. La premi\u00e8re transaction attend la lib\u00e9ration des donn\u00e9es bloqu\u00e9es par la seconde, tandis que la seconde attend la lib\u00e9ration des donn\u00e9es, bloqu\u00e9es par la premi\u00e8re.<\/i><\/p>\n

La solution optimiste au probl\u00e8me des interblocages permet que l'interblocage se produise, mais restaure ensuite le syst\u00e8me en annulant l'une des transactions impliqu\u00e9es dans l'interblocage.<\/h4>\n

\n\u00c0 des intervalles r\u00e9guliers, une recherche d'interblocages est effectu\u00e9e. L'un des moyens de d\u00e9tection consiste \u00e0 \u00e9valuer le temps, c'est-\u00e0-dire consid\u00e9rer qu'un interblocage s'est produit si une transaction s'ex\u00e9cute trop longtemps. Lorsque l'interblocage est identifi\u00e9, l'une des transactions est annul\u00e9e, permettant aux autres transactions impliqu\u00e9es dans l'interblocage de se terminer. Le choix de la transaction \u00e0 annuler peut \u00eatre bas\u00e9 sur le co\u00fbt des transactions ou sur leur anciennet\u00e9 (sch\u00e9mas Wait-Die et Wound-wait). <\/p>\n

\u00c0 chaque transaction des<\/b> est attribu\u00e9e un horodatage , donc pourquoi solliciter inutilement le scanner avec des manipulations et des v\u00e9rifications suppl\u00e9mentaires. Nous d\u00e9finirons le langage d'analyse en ajoutant un autre param\u00e8tre dans le fichier de configuration<\/b> indiquant l'heure du d\u00e9but d'ex\u00e9cution de la transaction.<\/p>\n

Wait-Die. <\/p>\n

Si TS(Ti)<\/b> < TS(Tj)<\/b>, alors Ti<\/b> attend, sinon Ti<\/b> elle est annul\u00e9e et recommence avec le m\u00eame horodatage.<\/u><\/p>\n

Si une transaction jeune a acquis une ressource et qu'une transaction plus ancienne demande la m\u00eame ressource, la transaction plus ancienne est autoris\u00e9e \u00e0 attendre. Si une transaction plus ancienne a acquis la ressource, alors la transaction jeune demandant cette ressource sera annul\u00e9e.<\/p>\n

Wound-wait. <\/p>\n

Si TS(Ti)<\/b> < TS(Tj)<\/b>, alors Tj<\/b> est annul\u00e9e et recommence avec le m\u00eame horodatage, sinon Ti<\/b> elle attend.<\/u><\/p>\n

Si une transaction plus jeune a acquis une ressource et qu'une transaction plus ancienne demande cette m\u00eame ressource, alors la transaction plus jeune sera annul\u00e9e. Si une transaction plus ancienne a acquis la ressource, alors la transaction plus jeune demandant cette ressource est autoris\u00e9e \u00e0 attendre. Le choix de la victime bas\u00e9 sur l'anciennet\u00e9 permet d'\u00e9viter l'apparition de blocages mutuels, mais annule des transactions qui ne sont pas dans un \u00e9tat de blocage mutuel. Le probl\u00e8me est que les transactions peuvent \u00eatre annul\u00e9es plusieurs fois, car une transaction plus ancienne peut retenir la ressource pendant longtemps.<\/p>\n

La solution pessimiste au probl\u00e8me de blocage mutuel n'autorise pas une transaction \u00e0 commencer son ex\u00e9cution s'il existe un risque de blocage mutuel.<\/h4>\n

\nPour d\u00e9tecter un blocage mutuel, un graphique est construit (graphique d'attente, wait-for-graph), dont les sommets sont des transactions et les ar\u00eates vont des transactions en attente de lib\u00e9ration des donn\u00e9es aux transactions ayant acquis ces donn\u00e9es. On consid\u00e8re qu'un blocage mutuel s'est produit si le graphique pr\u00e9sente des cycles. La construction du graphique d'attente, en particulier dans les bases de donn\u00e9es distribu\u00e9es, est une proc\u00e9dure co\u00fbteuse.<\/p>\n

Le verrouillage \u00e0 deux phases \u2014 pr\u00e9vention des blocages mutuels en acqu\u00e9rant toutes les ressources utilis\u00e9es par la transaction au d\u00e9but de celle-ci et en les lib\u00e9rant \u00e0 la fin.<\/h4>\n

\nToutes les op\u00e9rations de verrouillage doivent pr\u00e9c\u00e9der la premi\u00e8re op\u00e9ration de d\u00e9verrouillage. Cela a deux phases \u2014 la phase de croissance (Growing Phase) pendant laquelle les acquisitions s'accumulent et la phase de r\u00e9duction (Shrinking Phase) pendant laquelle les acquisitions sont lib\u00e9r\u00e9es. En cas d'impossibilit\u00e9 d'acqu\u00e9rir l'une des ressources, la transaction recommence. Il peut y avoir des situations o\u00f9 la transaction ne pourra pas acqu\u00e9rir les ressources requises, par exemple si plusieurs transactions doivent concourir pour les m\u00eames ressources.<\/p>\n

Le commit \u00e0 deux phases assure l'ex\u00e9cution du commit sur toutes les r\u00e9pliques de la base de donn\u00e9es.<\/h4>\n

\nChaque base de donn\u00e9es enregistre les informations sur les donn\u00e9es qui seront modifi\u00e9es dans un journal et r\u00e9pond au coordinateur par un OK (Voting Phase). Apr\u00e8s que toutes les r\u00e9ponses ont \u00e9t\u00e9 re\u00e7ues, le coordinateur envoie un signal obligatoire \u00e0 tous pour effectuer le commit. Apr\u00e8s le commit, de serveurs<\/a> les syst\u00e8mes r\u00e9pondent par OK, si au moins un n'a pas r\u00e9pondu OK, le coordinateur envoie un signal d'annulation des modifications \u00e0 tous les serveurs (Completion Phase).<\/p>\n

M\u00e9thode des horodatages<\/h2>\n

<\/p>\n

Une transaction plus ancienne est annul\u00e9e lors de la tentative d'acc\u00e8s aux donn\u00e9es auxquelles une transaction plus jeune a particip\u00e9.<\/h4>\n

\nChaque transaction se voit attribuer un horodatage , donc pourquoi solliciter inutilement le scanner avec des manipulations et des v\u00e9rifications suppl\u00e9mentaires. Nous d\u00e9finirons le langage d'analyse en ajoutant un autre param\u00e8tre dans le fichier de configuration<\/b> correspondant au d\u00e9but de son ex\u00e9cution. Si Ti<\/b> plus ancien Tj<\/b>, alors TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Lorsqu'une transaction est annul\u00e9e, elle se voit attribuer un nouvel horodatage. Chaque objet de donn\u00e9es Q<\/b> impliqu\u00e9 dans la transaction est marqu\u00e9 par deux horodatages. W-TS(Q)<\/b> \u2014 l'horodatage de la transaction la plus r\u00e9cente ayant r\u00e9ussi \u00e0 \u00e9crire sur Q<\/b>. R-TS(Q)<\/b> \u2014 l'horodatage de la transaction la plus r\u00e9cente ayant effectu\u00e9 une lecture sur Q<\/b>.<\/p>\n

Lorsque la transaction des<\/b> demande une lecture de donn\u00e9es Q<\/b> deux options sont possibles.<\/p>\n

Si TS(T)<\/b> < W-TS(Q)<\/b>, c'est-\u00e0-dire que les donn\u00e9es ont \u00e9t\u00e9 mises \u00e0 jour par une transaction plus r\u00e9cente, alors la transaction des<\/b> est annul\u00e9e.<\/u><\/p>\n

Si TS(T)<\/b> >= W-TS(Q)<\/b>, alors la lecture s'effectue et R-TS(Q)<\/b> devient MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Lorsque la transaction des<\/b> demande une modification des donn\u00e9es Q<\/b> deux options sont possibles. <\/p>\n

Si TS(T)<\/b> < R-TS(Q)<\/b>, c'est-\u00e0-dire que les donn\u00e9es ont d\u00e9j\u00e0 \u00e9t\u00e9 lues par une transaction plus r\u00e9cente et que si une modification est effectu\u00e9e, un conflit surviendra. La transaction des<\/b> est annul\u00e9e. <\/u><\/p>\n

Si TS(T)<\/b> < W-TS(Q)<\/b>, c'est-\u00e0-dire que la transaction essaie de r\u00e9\u00e9crire une valeur plus r\u00e9cente, la transaction T est annul\u00e9e. Dans les autres cas, la modification est effectu\u00e9e et W-TS(Q)<\/b> devient \u00e9gal \u00e0 TS(T)<\/b>.<\/u><\/p>\n

Aucun besoin de construire un graphe d'attente co\u00fbteux. Les transactions plus anciennes d\u00e9pendent de transactions plus r\u00e9centes, par cons\u00e9quent, il n'y a pas de cycles dans le graphe d'attente. Il n'y a pas de blocages, car les transactions n'attendent pas, mais sont imm\u00e9diatement annul\u00e9es. Des annulations en cascade peuvent se produire. Si Ti<\/b> a \u00e9t\u00e9 annul\u00e9e et Tj<\/b> a lu des donn\u00e9es qu'elle a modifi\u00e9es Ti<\/b>, alors Tj<\/b> doit \u00e9galement \u00eatre annul\u00e9e. Si de plus Tj<\/b> a d\u00e9j\u00e0 \u00e9t\u00e9 valid\u00e9e, alors cela violera le principe de durabilit\u00e9.<\/p>\n

Une des solutions aux annulations en cascade. La transaction effectue toutes les op\u00e9rations d'\u00e9criture \u00e0 la fin, tandis que les autres transactions doivent attendre la fin de cette op\u00e9ration. Les transactions attendent la validation avant de lire.<\/p>\n

R\u00e8gle de Thomas \u2014 une variation de la m\u00e9thode des horodatages o\u00f9 les donn\u00e9es mises \u00e0 jour par une transaction plus r\u00e9cente ne peuvent pas \u00eatre r\u00e9\u00e9crites par une ancienne<\/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\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\udd47Transactions et leurs m\u00e9canismes de contr\u00f4le | ProHoster","description":"Transaction Une transaction est une s\u00e9quence d'op\u00e9rations sur des donn\u00e9es avec un d\u00e9but et une fin. Une transaction consiste en l'ex\u00e9cution s\u00e9quentielle d'op\u00e9rations de lecture et d'\u00e9criture.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nLa transaction des<\/b> demande une modification des donn\u00e9es Q<\/b>. Si TS(T)<\/b> < W-TS(Q)<\/b>, c'est-\u00e0-dire que la transaction essaie de r\u00e9\u00e9crire une valeur plus r\u00e9cente, la transaction T n'est pas annul\u00e9e comme dans la m\u00e9thode des horodatages.
\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"