Serializzabilità e isolamento delle transazioni

Questa pagina descrive il conflitto, la serializzabilità e e l'isolamento dei dati. Per esempi di codice delle transazioni, consulta Transazioni e scritture collettive.

Transazioni e contesa dei dati

Affinché una transazione vada a buon fine, i documenti recuperati dalle relative operazioni di lettura e non devono essere modificati da operazioni esterne alla transazione. Se un'altra prova a modificare uno di questi documenti, l'operazione entra lo stato di contesa dei dati con la transazione.

Concorrenza dei dati
Quando due o più operazioni competono per controllare lo stesso documento. Ad esempio: una transazione può richiedere la coerenza di un documento mentre prova ad aggiornare i valori del campo di quel documento.

Cloud Firestore risolve il conflitto di dati ritardando o non superando una delle le operazioni. Le librerie client di Cloud Firestore riprova automaticamente a effettuare transazioni che non vanno a buon fine a causa del conflitto di dati. Dopo un numero limitato di nuovi tentativi, l'operazione di transazione non va a buon fine e restituisce un errore messaggio:

ABORTED: Too much contention on these documents. Please try again.

Nel decidere quale operazione non riesce o deve ritardare, il comportamento dipende dal tipo di libreria client.

  • Gli SDK mobile/web utilizzano controlli della concorrenza ottimistica.

  • Le librerie client del server utilizzano controlli di contemporaneità pessimistici.

Contesa dei dati negli SDK mobile/web

Gli SDK per dispositivi mobili/web (piattaforme Apple, Android, Web, C++) utilizzano controlli della contemporaneità ottimistici per risolvere i conflitti di dati.

Controlli della contemporaneità ottimistici
Sulla base del presupposto che il conflitto relativo ai dati non è probabile o che efficiente nel mantenere i blocchi dei database. Le transazioni ottimistiche non utilizzano il database blocchi per impedire ad altre operazioni di modificare i dati.

Gli SDK mobile/web usano controlli della contemporaneità ottimistici, perché possono operare ambienti con alta latenza e una connessione di rete inaffidabile. Chiusura in corso documenti in un ambiente ad alta latenza provocherebbe un conflitto eccessivo di dati errori.

Negli SDK per dispositivi mobili/web, una transazione tiene traccia di tutti i documenti che leggi all'interno della transazione. La transazione completa le proprie operazioni di scrittura solo se nessuno di questi documenti è stato modificato durante l'esecuzione della transazione. Se presente documento è stato modificato, il gestore della transazione riprova a eseguire la transazione. Se la transazione non può ottenere un risultato corretto dopo alcuni nuovi tentativi, a causa di un conflitto di dati.

Conflitto dei dati nelle librerie client del server

Le librerie client del server (C#, Go, Java, Node.js, PHP, Python, Ruby) utilizzano i pessimistici controlli di contemporaneità risolvono il conflitto tra i dati.

Controlli di contemporaneità pessimistici
Sulla base del presupposto che sia probabile un conflitto sui dati. Le transazioni pessimistiche utilizzano i blocchi del database per impedire ad altre operazioni di modificare i dati.

Le librerie client server utilizzano controlli di concorrenza pessimistici, poiché assumono una latenza ridotta e una connessione affidabile al database.

Nelle librerie client del server, le transazioni impongono dei blocchi sui documenti lette. Il blocco di una transazione su un documento blocca altre transazioni le scritture in batch e non transazionali dalla modifica del documento. Una transazione rilascia i blocchi dei documenti al momento del commit. Inoltre, rilascia i blocchi se si verifica il timeout o non funziona per qualsiasi motivo.

Quando una transazione blocca un documento, le altre operazioni di scrittura devono attendere transazione per rilasciare il relativo blocco. Le transazioni acquisiscono i loro vincoli in ordine cronologico.

Isolamento serializzabile

La contesa dei dati tra le transazioni è strettamente correlata ai livelli di isolamento del database. Il livello di isolamento di un database descrive l'efficacia del sistema gestisce i conflitti tra le operazioni simultanee. Il conflitto deriva dalla seguenti requisiti di database:

  • Le transazioni richiedono dati accurati e coerenti.
  • Per utilizzare le risorse in modo efficiente, i database eseguono operazioni contemporaneamente.

Nei sistemi con un livello di isolamento basso, un'operazione di lettura all'interno di una transazione potrebbe leggere dati inaccurati da modifiche non committate in un'operazione concorrente.

L'isolamento serializzabile definisce il livello di isolamento più elevato. Serializable isolamento significa che:

  • Puoi presumere che il database esegua le transazioni in serie.
  • Le transazioni non sono interessate da modifiche non impegnate nelle operazioni simultanee.

Questa garanzia deve essere valida anche quando il database esegue più transazioni in parallelo. Il database deve implementare controlli della contemporaneità per risolvere i conflitti che possono compromettere la garanzia.

Cloud Firestore garantisce l'isolamento serializzabile delle transazioni. Le transazioni in Cloud Firestore vengono serializzate e isolate in base al momento del commit.

Isolamento serializzabile per data di commit

Cloud Firestore assegna a ogni transazione un tempo di commit che rappresenta un singolo momento nel tempo. Quando Cloud Firestore esegue il commit delle modifiche di una transazione nel database, puoi assumere che tutte le letture e le scritture all'interno della transazione vengano eseguite esattamente al momento del commit.

L'esecuzione effettiva di una transazione richiede un certo periodo di tempo. L'esecuzione di un la transazione inizia prima della data del commit e l'esecuzione operazioni potrebbero sovrapporsi. Cloud Firestore supporta l'isolamento serializzabile e garantisce che:

  • Cloud Firestore esegue il commit delle transazioni in base alla data/ora di commit.
  • Cloud Firestore isola le transazioni dalle operazioni contemporaneamente con un momento di commit successivo.

Nel caso di conflitto di dati tra operazioni simultanee, Cloud Firestore utilizza controlli della contemporaneità ottimistici e pessimistici per risolvere i conflitti.

Isolamento all'interno di una transazione

L'isolamento delle transazioni si applica anche alle operazioni di scrittura all'interno di una transazione. Le query e le letture all'interno di una transazione non vedono i risultati delle scritture precedenti all'interno di quella transazione. Anche se modifichi o elimini un documento all'interno di una transazione, tutte le letture del documento nella transazione restituiscono la versione del documento al momento del commit, prima delle operazioni di scrittura della transazione. Le operazioni di lettura non restituiscono nulla se in quel momento il documento non esisteva.

Problemi di contesa dei dati

Per ulteriori informazioni sui conflitti di dati e su come risolverli, consulta la pagina relativa alla risoluzione dei problemi.