En esta página, se describen la contención, la serialización y el aislamiento de los datos de transacciones. Para ver muestras de código de transacciones, consulta el artículo Transacciones y escrituras en lotes.
Transacciones y contención de datos
Para que se realice correctamente una transacción, los documentos recuperados por sus operaciones de lectura deben permanecer sin modificaciones por operaciones fuera de la transacción. Si otra operación intenta modificar uno de esos documentos, queda en un estado de contención de datos con la transacción.
- Contención de datos
- Cuando dos o más operaciones compiten para controlar el mismo documento. Por ejemplo, una transacción puede requerir que se mantenga la coherencia de un documento mientras una operación simultánea intenta actualizar los valores de los campos de ese documento.
Para resolver la contención de datos, Cloud Firestore retrasa o rechaza una de las operaciones. Las bibliotecas cliente de Cloud Firestore reintentan automáticamente las transacciones que fallan debido a la contención de datos. Después de una cantidad limitada de reintentos, la operación de la transacción falla y se muestra un mensaje de error:
ABORTED: Too much contention on these documents. Please try again.
Para decidir qué operación se rechaza o retrasa, el comportamiento depende del tipo de controles de simultaneidad.
Controles de simultaneidad
El modo de simultaneidad es una opción de base de datos configurable. Cloud Firestore admite los siguientes modos de simultaneidad:
PESSIMISTIC: Los controles de simultaneidad pesimistas suponen que la contención de datos es probable. Las transacciones pesimistas usan bloqueos de la base de datos para evitar que otras operaciones modifiquen los datos.Con los controles de simultaneidad pesimistas, las transacciones aplican bloqueos en los documentos que leen. El bloqueo de una transacción en un documento evita que lo modifiquen otras transacciones, escrituras por lotes y escrituras no transaccionales. La transacción libera sus bloqueos de documentos en el momento de la confirmación y si se agota el tiempo de espera o falla por cualquier motivo.
Cuando una transacción bloquea un documento, otras operaciones de escritura deben esperar a que la transacción libere el bloqueo. Las transacciones aplican bloqueos en orden cronológico.
OPTIMISTIC: Los controles de simultaneidad optimista suponen que la contención de datos no es probable o que no es eficiente mantener los bloqueos de la base de datos. Las transacciones optimistas no usan bloqueos de bases de datos para impedir que otras operaciones modifiquen datos.Con los controles de simultaneidad optimista, una transacción realiza un seguimiento de todos los documentos que lees dentro de ella. Las transacciones completan sus operaciones de escritura solo si no se modificó ninguno de esos documentos durante su ejecución. Si cambió algún documento, el controlador de transacciones volverá a intentar la transacción. Si esta no puede obtener un resultado limpio después de algunos reintentos, fallará debido a la contención de datos.
Valores predeterminados del modo de simultaneidad
Los valores predeterminados son PESSIMISTIC y OPTIMISTIC
para la edición Standard y la Enterprise, respectivamente. Sin embargo, el comportamiento también depende del
tipo de biblioteca cliente:
Los SDK para dispositivos móviles y la Web usan controles de simultaneidad optimistas. Los SDKs para dispositivos móviles y la Web se comportan de forma independiente de este parámetro de configuración, ya que siempre emulan la simultaneidad optimista.
Las bibliotecas cliente de servidor usan los controles de simultaneidad de la configuración de la base de datos.
Contención de datos en los SDK para dispositivos móviles y la Web
Los SDK para dispositivos móviles y la Web emulan transacciones de simultaneidad optimista con
condiciones previas de escritura en las versiones de documentos. Esta emulación se produce independientemente de la
configuración del modo de simultaneidad de la base de datos. Los SDKs para dispositivos móviles y la Web no usan
la función de transacciones integradas,
por lo que, incluso si el modo de simultaneidad de la base de datos
está configurado como PESSIMISTIC, los clientes móviles seguirán comportándose de forma optimista.
Los SDK para dispositivos móviles y la Web usan controles de simultaneidad optimistas porque pueden funcionar en entornos con latencia alta y conexiones de red poco confiables. Si se bloquean documentos en un entorno de latencia alta, ocurrirían demasiadas fallas por la contención de datos.
Contención de datos en las bibliotecas cliente de servidor
Las bibliotecas cliente de servidor (C#, Go, Java, Node.js, PHP, Python y Ruby) usan la función de transacciones integradas. Estas transacciones usan el parámetro de configuración del modo de simultaneidad a nivel de la base de datos y el valor predeterminado depende de la edición:
De forma predeterminada, la edición Enterprise usa controles de simultaneidad optimista para admitir operaciones que analizan colecciones completas. Los controles de simultaneidad optimista ayudan a evitar las operaciones de análisis que se bloquean en una gran cantidad de documentos.
La edición Standard usa controles de simultaneidad pesimistas y supone una latencia baja y una conexión confiable con la base de datos.
Aislamiento serializable
La contención de datos entre transacciones se relaciona estrechamente con los niveles de aislamiento de las bases de datos. El nivel de aislamiento de una base de datos describe cómo controla el sistema los conflictos entre operaciones simultáneas. Estos provienen de los siguientes requisitos de bases de datos:
- Las transacciones requieren datos exactos y coherentes.
- Para usar recursos de manera eficiente, las bases de datos ejecutan operaciones de forma simultánea.
En los sistemas con un nivel de aislamiento bajo, una operación de lectura de una transacción puede leer datos inexactos de cambios no confirmados en una operación simultánea.
El aislamiento serializable es el nivel de aislamiento más alto. El aislamiento serializable implica lo siguiente:
- Puedes suponer que la base de datos ejecuta transacciones en serie.
- Los cambios no confirmados en operaciones simultáneas no afectan las transacciones.
Esta garantía debe mantenerse incluso mientras la base de datos ejecuta varias transacciones en paralelo. La base de datos debe implementar controles de simultaneidad para resolver los conflictos que podrían afectar esta garantía.
Cloud Firestore garantiza el aislamiento serializable de las transacciones. Las transacciones de Cloud Firestore se serializan y aíslan según el tiempo de confirmación.
Aislamiento serializable según el tiempo de confirmación
Cloud Firestore asigna a cada transacción un tiempo de confirmación que representa un momento específico. Cuando Cloud Firestore confirma los cambios de una transacción en la base de datos, puedes suponer que todas las lecturas y escrituras de la transacción se realizan exactamente en el momento de la confirmación.
La ejecución real de una transacción requiere un intervalo de tiempo. La ejecución de una transacción comienza antes del tiempo de confirmación y podría superponerse a la ejecución de varias operaciones. Cloud Firestore mantiene el aislamiento serializable y garantiza lo siguiente:
- Cloud Firestore confirma las transacciones en orden y según el tiempo de confirmación.
- Cloud Firestore aísla las transacciones de las operaciones simultáneas con un tiempo de confirmación posterior.
Cloud Firestore usa controles de simultaneidad optimistas y pesimistas para resolver los conflictos de datos entre operaciones simultáneas.
Aislamiento en una transacción
El aislamiento de transacciones también se aplica a las operaciones de escritura de una transacción. Las consultas y lecturas de una transacción no ven los resultados de las operaciones de escritura anteriores que se realizan en ella. Incluso si modificas o borras un documento en una transacción, todas las operaciones de lectura de documentos de esa transacción muestran la versión del documento correspondiente al momento de la confirmación, antes de que se apliquen las operaciones de escritura de la transacción. Las operaciones de lectura no muestran nada si el documento no existía en ese momento.
Problemas con contención de datos
Para obtener más información sobre la contención de datos y cómo resolverla, consulta la página de solución de problemas.