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 usuario empieza a actualizar filas, las filas se bloquean para evitar que otro usuario 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. 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. Para obtener información más detallada, consulte la documentación del DBMS.
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, funcionan los mismos mecanismos de bloqueo del DBMS subyacente que con cualquier otra aplicación; 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.
Al editar una geodatabase de SQL Server en una sesión de edición sin control de versiones, ArcGIS establece el nivel de aislamiento en UNCOMMITTED READ antes de cada transacción. No hay ninguna manera de cambiar o evitar este comportamiento; si establece el aislamiento en otro nivel antes de una transacción, ArcGIS lo establecerá de nuevo en UNCOMMITTED READ antes de que se inicie la transacción.
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
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 usuarios intentan editar la misma entidad al mismo tiempo, la entidad se bloquea cuando el primer usuario completa una operación. El bloqueo se continúa manteniendo, aunque este usuario esté trabajando en otras entidades. La entidad permanece bloqueada hasta que este usuario 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 usuario intenta modificar la misma entidad. La sesión de ArcMap del segundo usuario espera al bloqueo o a la liberación, mostrando el conocido reloj de arena. El reloj de arena se continúa mostrando hasta que se libera el bloqueo cuando el primer usuario 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 reloj de arena de la pantalla del segundo usuario desaparece, y se puede realizar la operación de edición del segundo usuario. (Observe que esto significa que las ediciones del segundo usuario sobrescriben las ediciones del primer usuario.)
Este problema de bloqueo también se puede producir simultáneamente entre dos usuarios cada vez que sucede lo siguiente:
- Los dos usuarios están editando simultáneamente.
- Los usuarios han modificado filas en su sesión de edición actual.
- Cada usuario intenta modificar una fila ya modificada por el otro usuario.
El primero de los usuarios 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 usuario intenta modificar una fila bloqueada por el primer usuario, se produce una situación conocida como interbloqueo, puesto que ambos usuarios 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 usuario 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 usuarios que escriben en la base de datos no impiden que otros usuarios lean los mismos datos, sin tener en cuenta el nivel de aislamiento. Para los usuarios que leen los datos bloqueados, aparecen como estaban antes de que se iniciara la transacción actual.
Los lectores no bloquean a los escritores: los usuarios que leen la base de datos no impiden que otros usuarios 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 información detallada, vea la explicación bajo "Oracle".
Los escritores bloquean a los lectores: en DB2 e Informix, los escritores impiden que otros usuarios 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 otro usuario agrega la misma capa a ArcMap, aparece el reloj de arena y la capa no se dibuja hasta que se liberen los bloqueos.
- Si otro usuario 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 otro usuario 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 usuarios 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 usuarios intentan editar la misma entidad al mismo tiempo, el primer usuario bloquea las actualizaciones del otro en esa fila. Otros usuarios no pueden editar esa fila hasta que este usuario 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 usuario intenta modificar la misma entidad. La sesión de ArcMap del segundo usuario espera al bloqueo o a la liberación, mostrando el conocido reloj de arena. El reloj de arena se continúa mostrando hasta que el primer usuario 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 reloj de arena de la pantalla del segundo usuario desaparece, y se puede realizar la operación de edición del segundo usuario. (Observe que esto significa que las ediciones del segundo usuario sobrescriben las ediciones del primer usuario.)
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 del usuario 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
ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción en una geodatabase de SQL Server. A continuación se describen algunos problemas de simultaneidad potenciales que pueden surgir dentro del contexto de ArcGIS. Para obtener más información sobre el nivel de aislamiento READ UNCOMMITTED, 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. Para obtener información detallada, vea la explicación bajo "Oracle".
Los escritores no bloquean a los lectores: dado que ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción, los escritores no bloquean a los lectores en las geodatabases de SQL Server. Sin embargo, cuando algunos usuarios están modificando los datos mientras otros están leyendo los mismos datos, es posible que los usuarios lean datos que se hayan cambiado pero todavía no se hayan confirmado. Esto se conoce como una lectura modificada y puede provocar que una consulta devuelva lo siguiente:
- Valores de datos inexactos
- Que no se devuelva ningún dato, cuando los datos existen
- Que se devuelvan datos duplicados cuando no existe ninguno
Los lectores no bloquean a los escritores: dado que ArcGIS establece el nivel de aislamiento en READ UNCOMMITTED antes de cada transacción, los lectores no bloquean a los escritores en las geodatabases de SQL Server.
Evitar problemas de simultaneidad
Afortunadamente, hay maneras de minimizar los problemas de simultaneidad:
Diseñe las aplicaciones y los flujos de trabajo pensando en los bloqueos: las solicitudes a la espera de la liberación de bloqueos suelen ser 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.
Establezca el nivel de aislamiento adecuado (Oracle, DB2, Informix): el nivel de aislamiento afecta a la cantidad de tiempo durante el 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.
Registre los datos como versionados: mejore la simultaneidad registrando los datos como versionados para trasladar las ediciones a la tabla base. Esto permite a los usuarios continuar manteniendo los datos con aplicaciones que no utilicen ArcGIS, pero aporta a los usuarios de la aplicación de ArcObjects y ArcGIS, que de otra manera se verían afectados por los problemas de simultaneidad, o que los provocarían, la capacidad de editar y administrar versiones de los datos. Cuando un usuario edita una versión, el usuario no aplica bloqueos, lo que permite editar los datos en aislamiento completo de otros usuarios.
El bloqueo de bases de datos es un tema complejo. Además, cada DBMS realiza el bloqueo 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.