Para ayudar a garantizar la integridad de los datos, todos los sistemas de administración de bases de datos (DBMS) aplican bloqueos a los datos. Por ejemplo, cuando un editor empieza a actualizar filas, las filas se bloquean para evitar que otro editor las modifique. Cuando la transacción ha finalizado, los bloqueos se liberan.
Cada DBMS aplica bloqueos e interpreta los niveles de aislamiento de manera diferente. Como resultado, es necesario estudiar el comportamiento del DBMS para determinar en qué nivel establecer los bloqueos, cómo establecer los niveles de aislamiento y cómo tratar los tiempos de espera de bloqueo y los interbloqueos. Para obtener información más detallada, consulte la documentación del DBMS.
Además, ArcGIS no funciona con todos los DBMS de la misma manera. Como resultado, la probabilidad de que se produzcan problemas de simultaneidad al realizar ediciones no versionadas difiere ligeramente entre los diversos DBMS. En este tema se proporciona una introducción breve a la aplicación de la simultaneidad y el bloqueo dentro del contexto de ArcGIS., pero el bloqueo de bases de datos es una cuestión compleja.
ArcGIS y los niveles de aislamiento
Al editar una geodatabase de Oracle, DB2 o Informix en una sesión de edición sin control de versiones, ArcGIS no modifica este entorno estableciendo el nivel de aislamiento. En su lugar, utiliza el nivel de aislamiento actual establecido en el DBMS. Como resultado, es posible establecer el aislamiento en cualquier nivel y hacer uso de ese nivel al editar en una sesión de edición sin control de versiones.
A partir de ArcGIS 10.4, las geodatabases en SQL Server deben tener las opciones de base de datos SQL Server READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION configuradas con el valor ON. Al editar una geodatabase de SQL Server en una sesión de edición sin control de versiones, ArcGIS utiliza el nivel de aislamiento READ COMMITTED para las transacciones.
En las siguientes secciones se describe el potencial para problemas de simultaneidad bajo condiciones comunes. A menos que se indique lo contrario, estas explicaciones suponen que se ha establecido el nivel de aislamiento predeterminado UNCOMMITTED READ, o su equivalente, en el DBMS subyacente.
Oracle 11g
Los escritores bloquean a los escritores: al realizar una operación de edición en una entidad o un grupo de entidades, tales como moverlas o modificar sus atributos, el DBMS bloquea las filas. Las entidades continúan bloqueadas hasta que se guarda o se detiene la sesión de edición sin guardar. Por consiguiente, cualquier entidad o registro que edite se bloqueará mientras dure la sesión de edición.
Cuando dos personas intentan editar la misma entidad al mismo tiempo, la entidad se bloquea cuando el primer editor completa una operación. El bloqueo se continúa manteniendo, aunque este editor esté trabajando en otras entidades. La entidad permanece bloqueada hasta que el editor guarde la sesión de edición, confirmando así los cambios en la base de datos, o la detenga sin guardar, lo que deshace todas las ediciones realizadas en esa sesión de edición.
Mientras la entidad está bloqueada, el segundo editor intenta modificar la misma entidad. La sesión de ArcMap del segundo editor espera a que el bloqueo se libere, y muestra un reloj de arena para mostrar que la sesión está procesando una acción. El reloj de arena se continúa mostrando hasta que se libera el bloqueo cuando el primer editor guarda los cambios (confirma los cambios en la base de datos) o finaliza la sesión de edición sin guardar los cambios (deshace las ediciones). En ese momento, el segundo editor puede editar la tabla. (Observe que esto significa que los cambios del segundo editor sobrescriben los cambios del primero).
Este problema de bloqueo también se puede producir simultáneamente entre dos editores cada vez que sucede lo siguiente:
- Ambos editan a la vez.
- Los editores han modificado filas en su sesión de edición actual.
- Cada editor intenta modificar una fila ya modificada por el otro.
El primero de los editores que intenta modificar una fila bloqueada ve un reloj de arena mientras la sesión de ArcMap espera a que se libere el bloqueo. Cuando el segundo editor intenta modificar una fila bloqueada por el primer editor, se produce una situación conocida como interbloqueo, puesto que ambos editores se están bloqueando entre sí. El DBMS elige rápidamente una de las transacciones para deshacerla, de modo que el otro pueda continuar. El editor cuya transacción se deshizo debe rehacer las ediciones realizadas desde que se guardaron las últimas ediciones.
Los escritores no bloquean a los lectores: los editores que escriben en la base de datos no impiden que otros lean los mismos datos independientemente del nivel de aislamiento. Para las personas o las aplicaciones que leen los datos bloqueados, aparecen como estaban antes de que se iniciara la transacción actual.
Los lectores no bloquean a los escritores: Las personas o las aplicaciones que leen la base de datos no impiden que otros modifiquen los mismos datos en cualquier nivel de aislamiento.
DB2 e Informix
Los escritores bloquean a los escritores: los escritores bloquean a los escritores en DB2 e Informix de manera similar a como los escritores bloquean a los escritores en Oracle. Para obtener más detalles, consulte la explicación en la Sección sobre Oracle.
Los escritores bloquean a los lectores: en DB2 e Informix, los escritores impiden que otras personas y aplicaciones lean los mismos datos en cualquier nivel de aislamiento superior a UNCOMMITTED READ. En estos niveles de aislamiento superiores, el bloqueo de los datos hasta que las ediciones se guardan o se deshacen pueden provocar problemas de simultaneidad; mientras está trabajando en una sesión de edición, nadie más puede leer los datos que está editando. Esto puede provocar que ocurra lo siguiente:
- Si se agrega la misma capa a ArcMap, aparece el reloj de arena y la capa no se dibuja hasta que se liberen los bloqueos.
- Si uno intenta desplazarse a los datos que se están editando, ArcMap espera a que se libere el bloqueo antes de actualizar la visualización.
- Si usted identifica una entidad bloqueada, el reloj de arena aparece y no se devuelve ninguna información hasta que se libere el bloqueo.
Los lectores bloquean a los escritores: en DB2 e Informix, los lectores pueden impedir que otros editores modifiquen los mismos datos en cualquier nivel de aislamiento superior a UNCOMMITTED READ. Sin embargo, en realidad esto apenas se nota en ArcGIS, puesto que los bloqueos de lectura sobre las filas se mantienen durante muy poco tiempo; en el momento en que aparecen los datos, ya se ha liberado el bloqueo. Los lectores solo pueden bloquear realmente a los escritores en una aplicación que abra un cursor en el DBMS, obtenga una fila cada vez y recorra el conjunto de resultados a medida que procesa los datos. En este caso, DB2 e Informix inician la adquisición y el mantenimiento de bloqueos cuando se procesa el conjunto de resultados.
PostgreSQL
Los escritores bloquean a los escritores: en PostgreSQL, una fila no se puede actualizar hasta que la primera transacción realizada en en la fila se confirma en la base de datos o se deshace. Cuando dos editores intentan actualizar o eliminar la misma entidad al mismo tiempo, el primer editor bloquea las actualizaciones del otro en esa fila. Otros editores no pueden editar esa fila hasta que este editor la guarde, confirmando los cambios en la base de datos, o detenga la sesión de edición sin guardar, lo que deshace todas las ediciones realizadas en esa sesión de edición.
Mientras la entidad está bloqueada, el segundo editor intenta modificar la misma entidad. La sesión de ArcMap del segundo editor espera a que el bloqueo se libere, y muestra un reloj de arena para mostrar que la sesión está procesando una acción. El reloj de arena se continúa mostrando hasta que el primer editor guarda sus cambios (confirma los cambios en la base de datos) o finaliza la sesión de edición sin guardar los cambios (deshace las ediciones). En ese momento, el segundo editor puede editar la tabla. (Observe que esto significa que los cambios del segundo editor sobrescriben los cambios del primero).
Los escritores no bloquean a los lectores: si utiliza el control de simultaneidad multiversión (MVCC) de PostgreSQL, que es el comportamiento predeterminado y recomendado para la base de datos, las transacciones que escriben en la base de datos no bloquean a los lectores que consultan la base de datos. Esto es verdad si se utiliza el nivel de aislamiento predeterminado READ COMMITTED en la base de datos o se establece el nivel de aislamiento en SERIALIZABLE.
Los lectores no bloquean a los escritores: no importa qué nivel de aislamiento se establezca en la base de datos, los lectores no bloquean los datos.
SQL Server
A partir de ArcGIS 10.4, las geodatabases en SQL Server deben tener las opciones de la base de datos SQL Server READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION configurados con el valor ON Y ArcGIS utiliza el nivel de aislamiento READ COMMITTED para las transacciones. Para obtener más información sobre el nivel de aislamiento READ COMMITTED, consulte la documentación de SQL Server.
Los escritores bloquean a los escritores: los escritores bloquean a los escritores en SQL Server de manera similar a como los escritores bloquean a los escritores en Oracle.
Los escritores no bloquean a los lectores: los lectores recuperan la versión confirmada de la fila que existía en el momento en que se inició la orden o la transacción.
Los lectores no bloquean a los escritores: cuando las transacciones se ejecutan bajo aislamiento basado en versionado de filas leen datos, las operaciones de lectura no adquieren bloqueos compartidos sobre los datos que se leen y, por consiguiente, no impiden a los editores modificar los datos. Además, esto reduce el número de bloqueos adquiridos y minimiza la sobrecarga de bloquear recursos. El aislamiento de lectura de confirmados mediante versionado de filas y el aislamiento mediante instantáneas están diseñados para proporcionar la coherencia de lectura en el nivel de orden o de transacción para los datos versionados.
Evitar problemas de simultaneidad
Los problemas de concurrencia se pueden minimizar siguiendo estas recomendaciones:
Diseñar las aplicaciones y los flujos de trabajo pensando en los bloqueos
A menudo, las solicitudes que quedan esperando a que los bloqueos se liberen son el resultado de aplicaciones o flujos de trabajo mal diseñados. Al desarrollar una aplicación o un flujo de trabajo, asegúrese de que los bloqueos se soliciten de manera organizada. Puede lograr esto normalizando la secuencia de actualizaciones en todas las tablas. Esto debería evitar los interbloqueos. Para reducir la cantidad de tiempo que se mantienen los bloqueos, es mejor emitir todas las solicitudes de modificación de datos al final de cada unidad de lógica de la aplicación o del flujo de trabajo que ejecute una transacción.
Establecer el nivel de aislamiento adecuado (Oracle, DB2, Informix)
El nivel de aislamiento afecta a la cantidad de tiempo que una transacción bloquea los datos. Cuanto más alto es el aislamiento, mas tiempo mantiene el bloqueo la transacción. Cuanto más tiempo mantiene el bloqueo la transacción, más aumenta la integridad de los datos, pero al precio de reducir la simultaneidad. Si es aceptable para la aplicación, puede reducir el nivel de aislamiento para mejorar la simultaneidad.
Registrar los datos como versionados
Mejore la concurrencia registrando los datos como versionados. Si se mantienen los datos mediante aplicaciones de terceros, piense en la posibilidad de registrar los datos como versionados con la opción de mover las ediciones a la tabla base. Esto permite a las aplicaciones de terceros ver los cambios aplicados a la versión predeterminada de geodatabase, pero añade la capacidad de que las aplicaciones de ArcGIS y ArcObjects, que de otro modo se verían afectados por problemas de concurrencia o provocar dichos problemas, puedan editar y administrar versiones de los datos. Cuando un editor edita una tabla versionada, no aplica bloqueos, lo que permite editar los datos en aislamiento completo de los demás usuarios.