Questa pagina descrive la contesa dei dati transazionali, la serializzabilità e l'isolamento. Per esempi di codice di transazione, consulta transazioni e operazioni di scrittura in batch.
Transazioni e contesa dei dati
Affinché una transazione vada a buon fine, i documenti recuperati dalle relative operazioni di lettura devono rimanere invariati dalle operazioni esterne alla transazione. Se un'altra operazione tenta di modificare uno di questi documenti, entra in uno stato di contesa dei dati con la transazione.
- Contesa dei dati
- Quando due o più operazioni competono per controllare lo stesso documento. Ad esempio, una transazione potrebbe richiedere che un documento rimanga coerente mentre un'operazione simultanea tenta di aggiornare i valori dei campi del documento.
Cloud Firestore risolve la contesa dei dati ritardando o non riuscendo a eseguire una delle operazioni. Le librerie client Cloud Firestore riprovano automaticamente le transazioni non riuscite a causa di conflitti di dati. Dopo un numero finito di tentativi, l'operazione di transazione non va a buon fine e viene restituito un messaggio di errore:
ABORTED: Too much contention on these documents. Please try again.
Quando si decide quale operazione non riuscirà o verrà ritardata, il comportamento dipende dal tipo di libreria client.
Gli SDK per dispositivi mobili/web utilizzano controlli di concorrenza ottimistica.
Le librerie client server utilizzano controlli di concorrenza pessimistici.
Contesa dei dati negli SDK web/per dispositivi mobili
Gli SDK per dispositivi mobili/web (piattaforme Apple, Android, web, C++) utilizzano controlli di concorrenza ottimistici per risolvere i conflitti di dati.
- Controlli della concorrenza ottimistici
- In base al presupposto che la contesa dei dati non sia probabile o che non sia efficiente mantenere i blocchi del database. Le transazioni ottimistiche non utilizzano blocchi del database per impedire ad altre operazioni di modificare i dati.
Gli SDK per dispositivi mobili/web utilizzano controlli di concorrenza ottimistici, perché possono operare in ambienti con latenza elevata e una connessione di rete inaffidabile. Il blocco dei documenti in un ambiente con latenza elevata causerebbe troppi errori di contesa dei dati.
Negli SDK web/mobile, una transazione tiene traccia di tutti i documenti che leggi al suo interno. La transazione completa le operazioni di scrittura solo se nessuno di questi documenti è stato modificato durante l'esecuzione della transazione. Se uno dei documenti è stato modificato, il gestore delle transazioni riprova a eseguire la transazione. Se la transazione non riesce a ottenere un risultato pulito dopo alcuni tentativi, la transazione non va a buon fine a causa della contesa dei dati.
Contesa dei dati nelle librerie client server
Le librerie client server (C#, Go, Java, Node.js, PHP, Python, Ruby) utilizzano controlli di concorrenza pessimistici per risolvere la contesa dei dati.
- Controlli della concorrenza pessimistici
- In base al presupposto che la contesa dei dati sia probabile. 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 perché presuppongono una bassa latenza e una connessione affidabile al database.
Nelle librerie client del server, le transazioni bloccano i documenti che leggono. Il blocco di una transazione su un documento impedisce ad altre transazioni, operazioni di scrittura in batch e operazioni di scrittura non transazionali di modificare il documento. Una transazione rilascia i blocchi dei documenti al momento del commit. Inoltre, rilascia i blocchi se si verifica un timeout o un errore per qualsiasi motivo.
Quando una transazione blocca un documento, le altre operazioni di scrittura devono attendere che la transazione rilasci il blocco. Le transazioni acquisiscono i blocchi 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 il modo in cui il sistema gestisce i conflitti tra operazioni simultanee. Il conflitto deriva dai seguenti requisiti del database:
- Le transazioni richiedono dati accurati e coerenti.
- Per utilizzare le risorse in modo efficiente, i database eseguono le operazioni contemporaneamente.
Nei sistemi con un livello di isolamento basso, un'operazione di lettura all'interno di una transazione potrebbe leggere dati imprecisi da modifiche non commit in un'operazione simultanea.
Isolamento serializzabile definisce il livello di isolamento più elevato. L'isolamento serializzabile significa che:
- Puoi presupporre che il database esegua le transazioni in serie.
- Le transazioni non sono interessate dalle modifiche non eseguite nelle operazioni simultanee.
Questa garanzia deve essere mantenuta anche mentre il database esegue più transazioni in parallelo. Il database deve implementare controlli di concorrenza per risolvere i conflitti che violerebbero questa garanzia.
Cloud Firestore garantisce l'isolamento serializzabile delle transazioni. Le transazioni in Cloud Firestore sono serializzate e isolate in base all'ora di commit.
Isolamento serializzabile per ora di commit
Cloud Firestore assegna a ogni transazione un orario di commit che rappresenta un singolo punto nel tempo. Quando Cloud Firestore esegue il commit delle modifiche di una transazione nel database, puoi supporre che tutte le letture e le scritture all'interno della transazione avvengano esattamente al momento del commit.
L'esecuzione effettiva di una transazione richiede un determinato periodo di tempo. L'esecuzione di una transazione inizia prima dell'ora di commit e l'esecuzione di più operazioni potrebbe sovrapporsi. Cloud Firestore mantiene l'isolamento serializzabile e garantisce che:
- Cloud Firestore esegue il commit delle transazioni in ordine in base all'ora del commit.
- Cloud Firestore isola le transazioni da operazioni simultanee con un orario di commit successivo.
In caso di contesa dei dati tra operazioni simultanee, Cloud Firestore utilizza controlli di concorrenza ottimistici e pessimistici per risolvere la contesa.
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 dei documenti in quella 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 il documento non esisteva.
Problemi di contesa dei dati
Per ulteriori informazioni sulla contesa dei dati e su come risolverla, consulta la pagina per la risoluzione dei problemi.