{"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 si compone dell'esecuzione sequenziale di operazioni di lettura e scrittura. La conclusione di una transazione pu\u00f2 essere o il salvataggio delle modifiche (commit) o il ripristino delle modifiche (rollback). In riferimento ai database, una transazione \u00e8 composta da pi\u00f9 query trattate come un'unica richiesta.<\/p>\n

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

\nAtomicit\u00e0. Una transazione viene eseguita completamente oppure non viene eseguita affatto.<\/p>\n

Coerenza. Al termine della transazione non devono essere violati i vincoli imposti sui dati (ad esempio, i constraints nei database). La coerenza implica 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 a vicenda, per esempio modificando i dati utilizzati da un'altra transazione. Il risultato dell'esecuzione di transazioni parallele deve essere tale da sembrare che siano state 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 effettuate dalle transazioni e garantisce l'atomicit\u00e0 e la durabilit\u00e0 dei dati in caso di guasto del sistema.<\/h4>\n

\nIl registro contiene i valori che i dati avevano prima e dopo le loro modifiche da parte della transazione. La strategia del write-ahead log richiede di registrare i valori precedenti all'inizio della transazione e i valori finali al termine della transazione. In caso di un arresto improvviso del sistema, il database legge il log in ordine inverso e annulla le modifiche apportate dalle transazioni. Incontrando una transazione interrotta, il database la esegue e registra le relative modifiche nel log. In presenza dello stato al momento del guasto, il database legge il log in ordine diretto e ripristina le modifiche apportate dalle transazioni. In questo modo si preserva la durabilit\u00e0 delle transazioni gi\u00e0 confermate e l'atomicit\u00e0 della transazione interrotta.<\/p>\n

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

Esempio. L'utente ha 500$ sul proprio conto e decide di prelevarli tramite un bancomat. Vengono eseguite due transazioni. La prima legge il valore del saldo e, se ci sono fondi sufficienti, eroga denaro all'utente. La seconda sottrae l'importo necessario dal saldo. Supponiamo che si sia verificato un errore di sistema e la prima operazione non sia riuscita, mentre la seconda s\u00ec. In questo caso, non possiamo riemettere il denaro all'utente senza ripristinare il sistema allo stato iniziale con un saldo positivo.<\/i><\/p>\n

Livelli di isolamento<\/h2>\n

<\/p>\n

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

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

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

La soluzione consiste nella lettura dei dati fissi (Read Committed) che vieta la lettura dei dati modificati da una transazione. Se la transazione A ha modificato un certo insieme di dati, allora la transazione B, richiedendo questi dati, deve attendere la conclusione della transazione A.<\/p>\n

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

\nIl problema delle modifiche perse (Lost Updates). T1 salva le modifiche sopra le modifiche di T2.<\/p>\n

Esempio. Valore iniziale del saldo 0$ e due transazioni aumentano simultaneamente il saldo. T1 e T2 leggono un saldo pari a 0$. Successivamente T2 aggiunge 200$ a 0$ e salva il risultato. T1 aggiunge 100$ a 0$ e salva il risultato. Il risultato finale \u00e8 100$ anzich\u00e9 300$.<\/i><\/p>\n

Il problema della lettura non ripetibile (Unrepeatable read). La lettura ripetuta dei medesimi dati restituisce valori diversi.<\/p>\n

Esempio. T1 legge un valore di saldo pari a 0$. Poi T2 aggiunge 50$ al saldo e si conclude. T1 legge di nuovo i dati e 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 insieme di dati, allora la transazione B, richiedendo questi dati, deve attendere la conclusione della transazione A.<\/p>\n

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

\nIl problema della lettura fantasma (Phantom Reads). Due richieste che selezionano dati in base a determinate condizioni restituiscono valori diversi.<\/p>\n

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

Lettura ordinata (Serializable). Le transazioni vengono eseguite come completamente sequenziali. Non \u00e8 consentito aggiornare o aggiungere record che ricadono sotto le condizioni di richiesta. Se la transazione A richiede dati dall'intera tabella, allora l'intera tabella viene bloccata 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 che avvengono in parallelo.<\/h4>\n

\nGarantisce un livello di isolamento stabilito. Se il risultato dell'esecuzione delle operazioni non dipende dal loro ordine, tali operazioni sono commutative (Permutable). Sono commutative le operazioni di lettura e le operazioni su dati diversi. Le operazioni di lettura-scrittura e scrittura-scrittura non sono commutative. Il compito del pianificatore \u00e8 quello 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 sulla prevenzione della comparsa di conflitti.<\/h4>\n

\nCon l'approccio ottimista, pi\u00f9 utenti ottengono a disposizione copie dei dati. Il primo che completa le modifiche salva le modifiche, mentre gli altri devono eseguire una fusione delle modifiche. L'algoritmo ottimista consente il verificarsi di conflitti, ma il sistema deve recuperarsi dopo il conflitto.<\/p>\n

Con l'approccio pessimista, il primo utente che acquisisce i dati impedisce agli altri di accedervi. Se i conflitti sono rari, \u00e8 ragionevole scegliere una strategia ottimista, in quanto garantisce un livello pi\u00f9 elevato di parallelismo.<\/p>\n

Bloccaggio (Locking)<\/h2>\n

<\/p>\n

Se una transazione ha bloccato i dati, le altre transazioni devono attendere lo sblocco quando accedono ai dati.<\/h4>\n

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

Il deadlock \u00e8 la situazione in cui le transazioni rimangono in attesa per un tempo indefinito.<\/h4>\n

\nEsempio. La prima transazione aspetta il rilascio dei dati bloccati dalla seconda, mentre la seconda aspetta il rilascio dei dati bloccati dalla prima.<\/i><\/p>\n

Una soluzione ottimistica al problema dei deadlock consente al deadlock di verificarsi, ma recupera il sistema tornando indietro a una delle transazioni coinvolte nel deadlock.<\/h4>\n

\nCon una certa periodicit\u00e0, si cerca il deadlock. Uno dei metodi di rilevamento \u00e8 basato sul tempo, cio\u00e8 si considera che si sia verificato un deadlock se una transazione impiega troppo tempo. Quando viene trovato un deadlock, una delle transazioni viene annullata, permettendo alle altre transazioni coinvolte nel deadlock di completarsi. La scelta della vittima pu\u00f2 essere basata sui costi delle transazioni o sulla loro anzianit\u00e0 (schemi Wait-Die e Wound-wait). <\/p>\n

A ogni transazione T<\/b> viene assegnato un timestamp TS<\/b> che contiene il tempo 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 pi\u00f9 giovane ha bloccato una risorsa, e una pi\u00f9 vecchia richiede la stessa risorsa, allora alla transazione pi\u00f9 anziana \u00e8 permesso attendere. Se una transazione pi\u00f9 anziana ha bloccato una risorsa, allora la transazione pi\u00f9 giovane che richiede quella risorsa verr\u00e0 annullata.<\/p>\n

Wound-wait. <\/p>\n

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

Se una transazione pi\u00f9 giovane ha acquisito una risorsa, e una transazione pi\u00f9 vecchia richiede la stessa risorsa, la transazione pi\u00f9 giovane verr\u00e0 annullata. Se una transazione pi\u00f9 vecchia ha acquisito la risorsa, alla transazione pi\u00f9 giovane che richiede questa risorsa \u00e8 permesso attendere. La selezione della vittima basata sull'anzianit\u00e0 previene l'emergere di blocchi reciproci, ma annulla transazioni che non si trovano in uno stato di blocco reciproco. Il problema \u00e8 che le transazioni possono essere annullate pi\u00f9 volte, poich\u00e9 una transazione pi\u00f9 vecchia pu\u00f2 trattenere a lungo la risorsa.<\/p>\n

Una soluzione pessimistica al problema dei blocchi reciproci non consente a una transazione di iniziare l'esecuzione se c'\u00e8 il rischio di un blocco reciproco.<\/h4>\n

\nPer rilevare un blocco reciproco viene costruito un grafo (grafo di attesa, wait-for-graph), i cui vertici sono le transazioni e i lati sono diretti dalle transazioni in attesa di liberare dei dati verso la transazione che ha acquisito questi dati. Si considera che ci sia un blocco reciproco se il grafo presenta ciclicit\u00e0. La costruzione del grafo di attesa, soprattutto nelle Basi Dati distribuite, \u00e8 una procedura costosa.<\/p>\n

Il blocco in due fasi previene i blocchi reciproci acquisendo tutte le risorse utilizzate dalla transazione all'inizio della transazione e rilasciandole alla fine.<\/h4>\n

\nTutte le operazioni di blocco devono precedere la prima operazione di sblocco. Ha due fasi: la Fase di Crescita in cui avviene l'accumulo delle acquisizioni e la Fase di Riduzione in cui avviene il rilascio delle acquisizioni. In caso di impossibilit\u00e0 di acquisire una delle risorse, la transazione ricomincia da capo. \u00c8 possibile che una transazione non riesca ad acquisire le risorse richieste, ad esempio se pi\u00f9 transazioni competono per le stesse risorse.<\/p>\n

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

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

Metodo dei timestamp<\/h2>\n

<\/p>\n

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

\nAd ogni transazione viene assegnato un timestamp TS<\/b> che corrisponde al momento di inizio dell'esecuzione. Se Ti<\/b> \u00e8 pi\u00f9 vecchio Tj<\/b>, allora TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Quando la transazione viene annullata, le viene assegnato un nuovo timestamp. Ogni oggetto dati Q<\/b> coinvolto nella transazione \u00e8 contrassegnato da due timestamp. W-TS(Q)<\/b> \u2014 il timestamp della transazione pi\u00f9 giovane che ha effettuato una scrittura su Q<\/b>. R-TS(Q)<\/b> \u2014 il timestamp della transazione pi\u00f9 giovane che ha effettuato una lettura su Q<\/b>.<\/p>\n

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

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

Se TS(T)<\/b> >= W-TS(Q)<\/b>, allora 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 ai dati Q<\/b> sono possibili due scenari. <\/p>\n

Se TS(T)<\/b> < R-TS(Q)<\/b>, vale a dire che i dati sono gi\u00e0 stati letti da una transazione pi\u00f9 giovane e se si tenta di effettuare una modifica, si verificher\u00e0 un conflitto. La transazione T<\/b> viene annullata. <\/u><\/p>\n

Se TS(T)<\/b> < W-TS(Q)<\/b>, cio\u00e8 se la transazione tenta di sovrascrivere un valore pi\u00f9 nuovo, la transazione T viene annullata. In tutti gli altri casi, la modifica viene eseguita e W-TS(Q)<\/b> diventa uguale a TS(T)<\/b>.<\/u><\/p>\n

Non \u00e8 necessario costruire un costoso grafo di attesa. 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 annullamenti a cascata. Se Ti<\/b> \u00e8 stata annullata, e Tj<\/b> ha letto i dati che ha modificato Ti<\/b>, allora Tj<\/b> deve anch'essa essere annullata. Se nel frattempo Tj<\/b> \u00e8 gi\u00e0 stata impegnata, si verificher\u00e0 una violazione del principio di resilienza.<\/p>\n

Una delle soluzioni per gli annullamenti a cascata. La transazione esegue tutte le operazioni di scrittura alla fine, mentre le altre transazioni devono aspettare il completamento di quest'operazione. Le transazioni aspettano il commit prima di leggere.<\/p>\n

Regola di scrittura di Thomas \u2014 una variazione del metodo dei timestamp 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":"Transazioni Una transazione \u00e8 una sequenza di operazioni sui dati che ha un inizio e una fine. Una transazione \u00e8 l'esecuzione sequenziale delle operazioni di lettura e scrittura.","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.","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}]}}

\nLa transazione T<\/b> richiede una modifica ai dati Q<\/b>Se TS(T)<\/b> < W-TS(Q)<\/b>, ossia se la transazione tenta di sovrascrivere un valore pi\u00f9 nuovo, 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":"