{"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\/it\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transazioni e meccanismi di controllo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transazioni<\/h2>\n

<\/p>\n

Una transazione \u00e8 una sequenza di operazioni sui dati che ha un inizio e una fine.<\/h4>\n

\nUna transazione implica l'esecuzione consecutiva di operazioni di lettura e scrittura. La fine di una transazione pu\u00f2 essere rappresentata dal salvataggio delle modifiche (commit) o dall'annullamento delle modifiche (rollback). Nel contesto di un database, una transazione consiste in pi\u00f9 query trattate come un'unica richiesta.<\/p>\n

Le transazioni devono soddisfare le propriet\u00e0 ACID.<\/h4>\n

\nAtomicit\u00e0. Una transazione deve essere eseguita interamente oppure non deve essere eseguita affatto.<\/p>\n

Coerenza. Al termine di una transazione, non devono essere violate le restrizioni imposte sui dati (ad esempio, i vincoli nei database). La coerenza presuppone che il sistema venga portato da uno stato corretto a un altro stato corretto.<\/p>\n

Isolamento. Le transazioni eseguite in parallelo non devono influenzarsi reciprocamente, ad esempio cambiando i dati utilizzati da un'altra transazione. Il risultato dell'esecuzione di transazioni parallele deve essere come se fossero eseguite in modo sequenziale.<\/p>\n

Durabilit\u00e0. Dopo il commit, le modifiche non devono andare perse.
\n<\/a><\/noindex><\/p>\n

Registro delle transazioni<\/h2>\n

<\/p>\n

Il registro conserva le modifiche apportate dalle transazioni, garantendo l'atomicit\u00e0 e la resilienza dei dati in caso di guasto del sistema.<\/h4>\n

\nIl registro contiene i valori che i dati avevano prima e dopo le modifiche effettuate dalla transazione. La strategia del write-ahead log richiede di aggiungere al registro una registrazione dei valori precedenti prima dell'inizio e dei valori finali dopo il completamento della transazione. In caso di arresto improvviso del sistema, il database legge il log in ordine inverso e annulla le modifiche apportate dalle transazioni. Quando incontra una transazione interrotta, il database la esegue e registra le modifiche nel log. Essendo nello stato al momento del guasto, il database legge il log in ordine diretto e ripristina le modifiche apportate dalle transazioni. In questo modo, si garantisce la resilienza delle transazioni gi\u00e0 confermate e l\u2019atomicit\u00e0 delle transazioni interrotte.<\/p>\n

Una semplice riesecuzione delle transazioni errate non \u00e8 sufficiente per il ripristino. <\/p>\n

Esempio. L'utente ha 500$ sul suo conto e decide di ritirarli tramite un bancomat. Vengono effettuate due transazioni. La prima legge il valore del saldo e, se il saldo \u00e8 sufficiente, eroga il denaro all'utente. La seconda sottrae l'importo necessario dal saldo. Supponiamo che si sia verificato un guasto di sistema e la prima operazione non sia riuscita, mentre la seconda \u00e8 andata a buon fine. In questo caso, non possiamo riemettere denaro all'utente senza riportare il sistema allo stato iniziale con un saldo positivo.<\/i><\/p>\n

Livelli di isolamento<\/h2>\n

<\/p>\n

Lettura dati confermati (Read Committed)<\/h4>\n

\nIl problema della lettura sporca (Dirty Read) sta nel fatto che una transazione pu\u00f2 leggere un risultato intermedio di un'altra transazione.<\/p>\n

Esempio. Il saldo iniziale \u00e8 0$. T1 aggiunge 50$ al saldo. T2 legge il valore del saldo (50$). T1 annulla le modifiche e termina. T2 continua l'esecuzione con dati errati sul saldo.<\/i><\/p>\n

La soluzione consiste nella lettura dei dati fissati (Read Committed), che vieta di leggere i dati modificati da una transazione. Se la transazione A modifica un certo insieme di dati, la transazione B, nel tentativo di accedere a tali dati, deve attendere il completamento della transazione A.<\/p>\n

Lettura ripetibile (Repeatable Read)<\/h4>\n

\nProblema delle modifiche perse (Lost Updates). T1 salva modifiche sovrascrivendo quelle di T2.<\/p>\n

Esempio. Il valore iniziale del saldo \u00e8 0$ e due transazioni incrementano simultaneamente il saldo. T1 e T2 leggono un saldo pari a 0$. Poi T2 aggiunge 200$ a 0$ e salva il risultato. T1 aggiunge 100$ a 0$ e salva il risultato. Il risultato finale \u00e8 100$ invece di 300$.<\/i><\/p>\n

Problema della lettura non ripetibile (Unrepeatable read). La rilettura degli stessi dati restituisce valori diversi.<\/p>\n

Esempio. T1 legge un valore di saldo pari a 0$. Poi T2 aggiunge 50$ al saldo e si completa. T1 rileggendo i dati scopre una discrepanza rispetto al risultato precedente.<\/i><\/p>\n

La lettura ripetibile (Repeatable Read) garantisce che la lettura ripetuta restituisca lo stesso risultato. I dati letti da una transazione non possono essere modificati da altre fino al completamento della transazione. Se la transazione A ha letto un certo set di dati, la transazione B, quando richiede questi dati, deve attendere il completamento della transazione A.<\/p>\n

Lettura ordinata (Serializable)<\/h4>\n

\nProblema della lettura fantasma (Phantom Reads). Due richieste che selezionano dati in base a una certa condizione restituiscono valori diversi.<\/p>\n

Esempio. T1 richiede il numero totale di utenti il cui saldo \u00e8 maggiore di 0$ ma inferiore a 100$. T2 sottrae 1$ da un utente con un saldo di 101$. T1 esegue nuovamente la richiesta.<\/i><\/p>\n

Lettura ordinata (Serializable). Le transazioni vengono eseguite come completamente sequenziali. \u00c8 vietato aggiornare e aggiungere record che rientrano nei criteri di richiesta. Se la transazione A richiede dati dell'intero tavolo, l'intera tabella viene congelata per le altre transazioni fino al completamento della transazione A.<\/p>\n

Pianificatore (Scheduler)<\/h2>\n

<\/p>\n

Stabilisce l'ordine in cui devono essere eseguite le operazioni durante le transazioni parallele.<\/h4>\n

\nGarantisce un certo livello di isolamento. Se il risultato delle operazioni non dipende dalla loro sequenza, queste operazioni sono commutative (Permutabili). Le operazioni di lettura e le operazioni su dati diversi sono commutative. Le operazioni di lettura-scrittura e scrittura-scrittura non sono commutative. Il compito del pianificatore \u00e8 di alternare le operazioni eseguite da transazioni parallele in modo che il risultato sia equivalente all'esecuzione sequenziale delle transazioni.<\/p>\n

Meccanismi di controllo della concorrenza (Concurrency Control)<\/h2>\n

<\/p>\n

Ottimista, basato sulla rilevazione e risoluzione dei conflitti; pessimista, mirato a prevenire l'insorgere dei conflitti.<\/h4>\n

\nCon l'approccio ottimista, pi\u00f9 utenti hanno a disposizione copie dei dati. Il primo a completare le modifiche salva le modifiche, mentre gli altri devono unire le modifiche. L'algoritmo ottimista consente il verificarsi di un conflitto, ma il sistema deve riprendersi dopo il conflitto.<\/p>\n

In un approccio pessimista, il primo utente che acquisisce i dati impedisce agli altri di ottenere quelle informazioni. Se i conflitti sono rari, \u00e8 ragionevole scegliere una strategia ottimistica, poich\u00e9 essa garantisce un livello di parallelismo pi\u00f9 elevato.<\/p>\n

Blocco (Locking)<\/h2>\n

<\/p>\n

Se una transazione ha bloccato i dati, le altre transazioni che tentano di accedervi devono attendere lo sblocco.<\/h4>\n

\nIl blocco pu\u00f2 essere applicato a un database, una tabella, una riga o un attributo. Il blocco condiviso (Shared Lock) pu\u00f2 essere applicato sui dati da pi\u00f9 transazioni, consentendo a tutte le transazioni (inclusa quella che ha applicato il blocco) di leggere, ma vietando modifiche e blocchi esclusivi. Il blocco esclusivo (Exclusive Lock) pu\u00f2 essere applicato solo da una transazione, consentendo qualsiasi operazione alla transazione che lo ha applicato, ma vietando qualsiasi operazione alle altre.<\/p>\n

Una situazione di deadlock si verifica quando le transazioni si trovano in uno stato di attesa che dura indefinitamente.<\/h4>\n

\nEsempio. La prima transazione attende lo sblocco dei dati acquisiti dalla seconda, mentre la seconda attende lo sblocco dei dati acquisiti dalla prima.<\/i><\/p>\n

La soluzione ottimistica per il problema dei deadlock consente che si verifichi un deadlock, ma poi ripristina il sistema annullando una delle transazioni coinvolte nel deadlock.<\/h4>\n

\nCon una certa periodicit\u00e0 viene eseguita la ricerca di deadlock. Uno dei modi per individuarli \u00e8 basato sul tempo, ovvero si considera che un deadlock sia avvenuto se una transazione dura troppo a lungo. Quando viene trovato un deadlock, una delle transazioni viene annullata, permettendo cos\u00ec alle altre transazioni coinvolte di completarsi. La scelta della vittima pu\u00f2 basarsi sul costo delle transazioni o sulla loro anzianit\u00e0 (schemi Wait-Die e Wound-wait). <\/p>\n

Ad ogni transazione T<\/b> viene assegnato un timestamp TS<\/b> che contiene l'ora di inizio dell'esecuzione della transazione.<\/p>\n

Wait-Die. <\/p>\n

Se TS(Ti)<\/b> < TS(Tj)<\/b>, allora Ti<\/b> aspetta, altrimenti Ti<\/b> viene annullata e inizia di nuovo con lo stesso timestamp.<\/u><\/p>\n

Se una transazione giovane ha acquisito una risorsa e una pi\u00f9 vecchia richiede la stessa risorsa, allora la transazione pi\u00f9 anziana pu\u00f2 aspettare. Se una transazione pi\u00f9 vecchia ha acquisito la risorsa, la transazione giovane che richiede quella risorsa verr\u00e0 annullata.<\/p>\n

Wound-wait. <\/p>\n

Se TS(Ti)<\/b> < TS(Tj)<\/b>, allora Tj<\/b> rollback e ricomincia con lo stesso timestamp, altrimenti Ti<\/b> attende.<\/u><\/p>\n

Se una transazione pi\u00f9 giovane acquisisce una risorsa e una transazione pi\u00f9 vecchia richiede la stessa risorsa, la transazione giovane verr\u00e0 annullata. Se una transazione pi\u00f9 vecchia acquisisce una risorsa, la transazione pi\u00f9 giovane che richiede quella risorsa \u00e8 autorizzata ad attendere. La scelta della vittima basata sull'et\u00e0 previene l'insorgere di deadlock, ma rollbacka transazioni che non sono in uno stato di deadlock. Il problema \u00e8 che le transazioni possono essere annullate pi\u00f9 volte, poich\u00e9 una transazione pi\u00f9 vecchia pu\u00f2 mantenere a lungo la risorsa.<\/p>\n

Una soluzione pessimistica al problema dei deadlock non consente l'esecuzione della transazione se c'\u00e8 il rischio di un deadlock<\/h4>\n

\nPer rilevare un deadlock, viene costruito un grafo (grafo di attesa, wait-for-graph), dove i nodi rappresentano le transazioni e gli archi sono orientati dalle transazioni in attesa del rilascio dei dati verso le transazioni che hanno acquisito tali dati. Si considera che ci sia un deadlock se il grafo presenta cicli. La costruzione del grafo di attesa, specialmente in database distribuiti, \u00e8 un'operazione costosa.<\/p>\n

Il locking a due fasi previene i deadlock attraverso l'acquisizione di tutte le risorse utilizzate dalla transazione all'inizio e il rilascio delle stesse alla fine.<\/h4>\n

\nTutte le operazioni bloccanti devono precedere la prima operazione di sblocco. Presenta due fasi: la fase di crescita (Growing Phase) in cui avviene l'accumulo delle acquisizioni, e la fase di riduzione (Shrinking Phase) in cui avviene il rilascio delle acquisizioni. Se non \u00e8 possibile acquisire una delle risorse, la transazione ricomincia da capo. Pu\u00f2 verificarsi la situazione in cui una transazione non riesce ad acquisire le risorse necessarie, ad esempio se pi\u00f9 transazioni competono per le stesse risorse.<\/p>\n

Il commit a due fasi assicura l'esecuzione del commit su tutte le repliche del database.<\/h4>\n

\nOgni database registra le informazioni sui dati che saranno modificati nel log e risponde al coordinatore con un OK (Fase di Votazione). Una volta che tutti hanno risposto con OK, il coordinatore invia un segnale che obbliga tutti a eseguire il commit. Dopo il commit server<\/a> rispondono con OK; se anche solo uno non risponde con OK, il coordinatore invia un segnale di annullamento delle modifiche a tutti i server (Fase di Completamento).<\/p>\n

Metodo delle timestamp<\/h2>\n

<\/p>\n

Una transazione pi\u00f9 vecchia viene annullata se tenta di accedere ai dati utilizzati da una transazione pi\u00f9 giovane<\/h4>\n

\nA ciascuna transazione viene assegnata una timestamp TS<\/b> che corrisponde al momento di inizio dell'esecuzione. Se Ti<\/b> \u00e8 pi\u00f9 vecchia Tj<\/b>, allora TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Quando una transazione viene annullata, le viene assegnata una nuova timestamp. Ogni oggetto dati Q<\/b> coinvolto nella transazione \u00e8 contrassegnato da due timestamp. W-TS(Q)<\/b> \u2014 la timestamp della transazione pi\u00f9 giovane che ha eseguito con successo una scrittura su Q<\/b>. R-TS(Q)<\/b> \u2014 la timestamp della transazione pi\u00f9 giovane che ha eseguito una scrittura di lettura su Q<\/b>.<\/p>\n

Quando la transazione T<\/b> richiede di leggere i dati Q<\/b> sono possibili due scenari.<\/p>\n

Se TS(T)<\/b> < W-TS(Q)<\/b>, ovvero i dati sono stati aggiornati da una transazione pi\u00f9 giovane, quindi la transazione T<\/b> viene annullata.<\/u><\/p>\n

Se TS(T)<\/b> >= W-TS(Q)<\/b>, quindi la lettura viene eseguita e R-TS(Q)<\/b> diventa MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Quando la transazione T<\/b> richiede una modifica dei dati Q<\/b> sono possibili due scenari. <\/p>\n

Se TS(T)<\/b> < R-TS(Q)<\/b>, cio\u00e8 i dati sono gi\u00e0 stati letti da una transazione pi\u00f9 giovane e se si effettuano modifiche, si verificher\u00e0 un conflitto. La transazione T<\/b> viene annullata. <\/u><\/p>\n

Se TS(T)<\/b> < W-TS(Q)<\/b>, cio\u00e8 la transazione sta cercando di sovrascrivere un valore pi\u00f9 recente, la transazione T viene annullata. Negli altri casi, la modifica viene eseguita e W-TS(Q)<\/b> diventa uguale a TS(T)<\/b>.<\/u><\/p>\n

Non \u00e8 necessaria una costosa costruzione del grafo delle attese. Le transazioni pi\u00f9 vecchie dipendono da quelle pi\u00f9 nuove, quindi nel grafo delle attese non ci sono cicli. Non ci sono deadlock, poich\u00e9 le transazioni non aspettano, ma vengono annullate immediatamente. Possono verificarsi rollback a cascata. Se Ti<\/b> \u00e8 stata annullata, e Tj<\/b> ha letto i dati che ha modificato Ti<\/b>, allora Tj<\/b> deve essere annullata anch'essa. Se in tal caso Tj<\/b> era gi\u00e0 stata committata, si verificher\u00e0 una violazione del principio di coerenza.<\/p>\n

Una delle soluzioni ai rollback a cascata. La transazione esegue tutte le operazioni di scrittura alla fine, e quindi le altre transazioni devono attendere il completamento di quest'operazione. Le transazioni aspettano il commit prima di leggere.<\/p>\n

La regola di scrittura di Thomas \u2014 una variazione del metodo degli orari in cui i dati aggiornati da una transazione pi\u00f9 giovane non possono essere sovrascritti da una pi\u00f9 vecchia<\/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\udd47Transazioni e meccanismi di controllo | ProHoster","description":"Le transazioni sono una sequenza di operazioni sui dati che ha un inizio e una fine. Una transazione consiste nell'esecuzione sequenziale di operazioni di lettura e scrittura. La conclusione di una transazione pu\u00f2 essere il salvataggio delle modifiche (commit) o l'annullamento delle modifiche (rollback). In relazione ai database, una transazione \u00e8 composta da pi\u00f9 richieste che vengono trattate come una singola richiesta. Le transazioni devono soddisfare le propriet\u00e0 ACID: Atomariet\u00e0. Una transazione viene eseguita completamente oppure non viene eseguita affatto.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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. \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","og:url":"https:\/\/prohoster.info\/it\/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\/it\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransazione T<\/b> richiede una modifica dei dati Q<\/b>. Se TS(T)<\/b> < W-TS(Q)<\/b>, ovvero la transazione sta cercando di sovrascrivere un valore pi\u00f9 recente, la transazione T non viene annullata come nel metodo dei timestamp.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"