Cette page décrit les conflits de données transactionnelles, la sérialisabilité et l'isolation. Pour obtenir des exemples de codes de transaction, consultez plutôt transactions et écritures par lots.
Transactions et conflits de données
Pour qu'une transaction réussisse, les documents récupérés par ses opérations de lecture doivent rester non modifiés par des opérations extérieures à la transaction. Si une autre opération tente de modifier l’un de ces documents, cette opération entre dans un état de conflit de données avec la transaction.
- Conflit de données
- Lorsque deux ou plusieurs opérations sont en concurrence pour contrôler le même document. Par exemple, une transaction peut nécessiter qu'un document reste cohérent pendant qu'une opération simultanée tente de mettre à jour les valeurs des champs de ce document.
Cloud Firestore résout les conflits de données en retardant ou en faisant échouer l'une des opérations. Les bibliothèques clientes Cloud Firestore réessayent automatiquement les transactions qui échouent en raison d'un conflit de données. Après un nombre fini de tentatives, l'opération de transaction échoue et renvoie un message d'erreur :
ABORTED: Too much contention on these documents. Please try again.
Lorsque vous décidez quelle opération échouer ou retarder, le comportement dépend du type de bibliothèque cliente.
Les SDK mobiles/Web utilisent des contrôles de concurrence optimistes.
Les bibliothèques clientes du serveur utilisent des contrôles de concurrence pessimistes.
Conflit de données dans les SDK mobiles/Web
Les SDK mobiles/Web (plateformes Apple, Android, Web, C++) utilisent des contrôles de concurrence optimistes pour résoudre les conflits de données.
- Contrôles de concurrence optimistes
- Basé sur l'hypothèse que les conflits de données sont peu probables ou qu'il n'est pas efficace de maintenir des verrous de base de données. Les transactions optimistes n'utilisent pas de verrous de base de données pour empêcher d'autres opérations de modifier les données.
Les SDK mobiles/Web utilisent des contrôles de concurrence optimistes, car ils peuvent fonctionner dans des environnements avec une latence élevée et une connexion réseau peu fiable. Verrouiller des documents dans un environnement à latence élevée entraînerait trop d'échecs de conflit de données.
Dans les SDK Mobile/Web, une transaction garde une trace de tous les documents que vous lisez au sein de la transaction. La transaction termine ses opérations d'écriture uniquement si aucun de ces documents n'a changé pendant l'exécution de la transaction. Si un document a été modifié, le gestionnaire de transactions réessaye la transaction. Si la transaction ne parvient pas à obtenir un résultat net après quelques tentatives, la transaction échoue en raison d'un conflit de données.
Conflit de données dans les bibliothèques clientes du serveur
Les bibliothèques clientes du serveur (C#, Go, Java, Node.js, PHP, Python, Ruby) utilisent des contrôles de concurrence pessimistes pour résoudre les conflits de données.
- Contrôles de concurrence pessimistes
- Basé sur l’hypothèse que des conflits de données sont probables. Les transactions pessimistes utilisent des verrous de base de données pour empêcher d'autres opérations de modifier les données.
Les bibliothèques client serveur utilisent des contrôles de concurrence pessimistes, car ils supposent une faible latence et une connexion fiable à la base de données.
Dans les bibliothèques clientes du serveur, les transactions placent des verrous sur les documents qu'elles lisent. Le verrouillage d'une transaction sur un document empêche les autres transactions, les écritures par lots et les écritures non transactionnelles de modifier ce document. Une transaction libère ses verrous de document au moment de la validation. Il libère également ses verrous en cas d'expiration ou d'échec pour une raison quelconque.
Lorsqu'une transaction verrouille un document, les autres opérations d'écriture doivent attendre que la transaction libère son verrou. Les transactions acquièrent leurs verrous par ordre chronologique.
Isolement sérialisable
Les conflits de données entre les transactions sont étroitement liés aux niveaux d'isolement des bases de données. Le niveau d'isolement d'une base de données décrit dans quelle mesure le système gère les conflits entre les opérations simultanées. Le conflit provient des exigences de base de données suivantes :
- Les transactions nécessitent des données précises et cohérentes.
- Pour utiliser efficacement les ressources, les bases de données exécutent des opérations simultanément.
Dans les systèmes dotés d'un faible niveau d'isolement, une opération de lecture au sein d'une transaction peut lire des données inexactes provenant de modifications non validées dans une opération simultanée.
L'isolement sérialisable définit le niveau d'isolement le plus élevé. L'isolement sérialisable signifie que :
- Vous pouvez supposer que la base de données exécute les transactions en série.
- Les transactions ne sont pas affectées par les modifications non validées des opérations simultanées.
Cette garantie doit être valable même lorsque la base de données exécute plusieurs transactions en parallèle. La base de données doit implémenter des contrôles de concurrence pour résoudre les conflits qui briseraient cette garantie.
Cloud Firestore garantit une isolation sérialisable des transactions. Les transactions dans Cloud Firestore sont sérialisées et isolées par heure de validation.
Isolation sérialisable par temps de validation
Cloud Firestore attribue à chaque transaction une heure de validation qui représente un instant unique dans le temps. Lorsque Cloud Firestore valide les modifications d'une transaction dans la base de données, vous pouvez supposer que toutes les lectures et écritures au sein de la transaction ont lieu exactement au moment de la validation.
L'exécution réelle d'une transaction nécessite un certain laps de temps. L'exécution d'une transaction commence avant l'heure de validation et l'exécution de plusieurs opérations peut se chevaucher. Cloud Firestore maintient l'isolation sérialisable et garantit que :
- Cloud Firestore valide les transactions dans l'ordre par heure de validation.
- Cloud Firestore isole les transactions des opérations simultanées avec une heure de validation ultérieure.
En cas de conflit de données entre opérations simultanées, Cloud Firestore utilise des contrôles de concurrence optimistes et pessimistes pour résoudre les conflits.
Isolement au sein d'une transaction
L'isolation des transactions s'applique également aux opérations d'écriture au sein d'une transaction. Les requêtes et les lectures au sein d'une transaction ne voient pas les résultats des écritures précédentes au sein de cette transaction. Même si vous modifiez ou supprimez un document au sein d'une transaction, tous les documents lus dans cette transaction renvoient la version du document au moment de la validation, avant les opérations d'écriture de la transaction. Les opérations de lecture ne renvoient rien si le document n'existait pas à ce moment-là.
Problèmes de conflit de données
Pour plus d'informations sur les conflits de données et comment les résoudre, consultez la page de dépannage .