Tous les systèmes de gestion de base de données peuvent verrouiller des données afin de maintenir leur intégrité. Par exemple, lorsqu'un éditeur entame la mise à jour de lignes, celles-ci se verrouillent pour empêcher un autre éditeur de les modifier. Une fois la transaction terminée, les données sont déverrouillées.
Chaque système de gestion de base de données présente une manière différente d’appliquer les verrouillages et d’interpréter les niveaux d’isolement. En conséquence, vous devez étudier le comportement de votre SGBD afin de déterminer le niveau de verrouillage requis, ainsi que la méthode de définition des niveaux d'isolement et de gestion des expirations de verrouillage et arrêts fatals. Pour en savoir plus, consultez la documentation de votre SGBD.
En outre, ArcGIS ne gère pas tous les systèmes de gestion de base de données de la même manière. En conséquence, les problèmes d’accès simultané éventuels en cas de mises à jour non versionnées varient légèrement. Cette rubrique présente succinctement le fonctionnement de l'accès simultané et du verrouillage dans ArcGIS, mais le verrouillage des bases de données est un sujet complexe. Pour plus d’informations sur ce concept, consultez la documentation relative à votre système de gestion de base de données et les documents d’administration de la base de données.
ArcGIS et niveaux d'isolement
Lorsque vous modifiez une géodatabase dans Oracle, Db2 ou Informix dans une session de mise à jour non versionnée, ArcGIS ne modifie pas cet environnement en définissant le niveau d'isolement. Il utilise plutôt le niveau d'isolement actuel défini dans le SGBD. En conséquence, vous pouvez définir le niveau d'isolement et l'appliquer lors d'une session de mise à jour non versionnée.
A partir d'ArcGIS 10.4, les options de base de données SQL Server READ_COMMITTED_SNAPSHOT et ALLOW_SNAPSHOT_ISOLATION doivent être définies sur ON dans les géodatabases dans SQL Server. Lorsque vous modifiez une géodatabase dans SQL Server dans une session de mise à jour non versionnée, ArcGIS utilise le niveau d'isolement READ COMMITTED pour les transactions.
Les sections suivantes décrivent les problèmes d'accès simultané éventuels dans des conditions normales. Sauf indication contraire, ces explications supposent que le niveau d'isolement LECTURE VALIDEE, ou un niveau équivalent, est défini dans le SGBD sous-jacent.
Oracle
Les rédacteurs bloquent les rédacteurs : lorsque vous effectuez une opération de mise à jour sur une entité ou un groupe d'entités, par exemple en les déplaçant ou en modifiant leurs attributs, le SGBD verrouille les enregistrements. Les entités restent verrouillées tant que vous n'avez pas enregistré vos modifications ou fermé la session de mise à jour sans enregistrer les modifications. Par conséquent, tout(e) entité ou enregistrement que vous modifiez est verrouillé(e) pendant votre session de mise à jour.
Lorsque deux personnes essaient de modifier simultanément la même entité, celle-ci se verrouille lorsque le premier éditeur termine une opération. Le verrouillage reste actif même si cet éditeur modifie d'autres entités. L'entité reste verrouillée jusqu'à ce que l'éditeur enregistre (et, ce faisant, valide les modifications dans la base de données) ou interrompe la session de mise à jour sans enregistrer (ce qui a pour effet d'annuler toutes les mises à jour effectuées lors de cette session).
Pendant le verrouillage de l'entité, le second éditeur tente de modifier la même entité. Sa session ArcMap attend le déverrouillage de l'entité et affiche un sablier indiquant qu'elle traite une action. Le sablier reste affiché jusqu'à ce que le verrouillage soit levé, lorsque le premier éditeur enregistre les modifications (les valide dans la base de données) ou interrompt la session de mise à jour sans enregistrer les modifications effectuées (annule toutes les mises à jour effectuées). Le second éditeur peut alors mettre à jour la table. (Cela signifie que les modifications du second éditeur remplacent celles du premier éditeur.)
Ce problème de verrouillage peut également survenir simultanément entre deux éditeurs dans les cas suivants :
- Les deux procèdent à une mise à jour simultanée.
- Les éditeurs ont modifié des lignes dans leur session de mise à jour actuelle.
- Chaque éditeur tente de modifier une ligne qui a déjà été modifiée par l'autre.
Le premier des éditeurs qui tente de modifier une ligne verrouillée voit s'afficher un sablier, ce qui indique que la session ArcMap attend le déverrouillage de la ligne. Lorsque le second éditeur tente de modifier une ligne verrouillée par le premier éditeur, une situation connue sous le terme d'arrêt fatal survient car les deux éditeurs se bloquent mutuellement. Le SGBD choisit rapidement d'annuler l'une des transactions afin que l'autre puisse continuer. L'éditeur dont la transaction a été annulée doit recommencer les mises à jour effectuées depuis le dernier enregistrement.
Les rédacteurs ne bloquent pas les lecteurs : les éditeurs qui modifient des informations dans la base de données n'empêchent pas les autres de lire ces mêmes informations, indépendamment du niveau d'isolement. Pour les personnes ou applications qui lisent les données verrouillées, ces informations apparaissent telles qu'elles étaient avant le début de la transaction actuelle.
Les lecteurs ne bloquent pas les rédacteurs : les personnes ou applications qui lisent la base de données n'empêchent pas les autres de modifier ces mêmes données, indépendamment du niveau d'isolement.
Db2 et Informix
Les rédacteurs bloquent les rédacteurs : les rédacteurs bloquent d'autres rédacteurs dans Db2 et Informix, à l'instar du fonctionnement dans Oracle. Pour en savoir plus, consultez l'explication de la section Oracle.
Les rédacteurs bloquent les lecteurs : dans Db2 et Informix, les rédacteurs empêchent d'autres personnes et applications de lire les mêmes données, quel que soit le niveau d'isolement supérieur au niveau LECTURE NON VALIDEE. A ces niveaux d'isolement supérieurs, le verrouillage des données jusqu'à l'enregistrement ou l'annulation des modifications peut engendrer des problèmes d'accès simultané. En effet, lorsque que vous ouvrez une session de mise à jour, personne ne peut lire les données que vous modifiez. Ceci peut entraîner les problèmes suivants :
- Si vous ajoutez la même couche à ArcMap, le sablier apparaît et la couche n'est pas dessinée tant que les données n'ont pas été déverrouillées.
- Si vous tentez d'accéder aux données en cours de modification, ArcMap attend le déverrouillage de ces données avant d'actualiser l'affichage.
- Si vous identifiez une entité verrouillée, le sablier apparaît et aucune information n'est renvoyée tant que l'entité n'a pas été déverrouillée.
Les lecteurs bloquent les rédacteurs : dans Db2 et Informix, les lecteurs peuvent empêcher d'autres éditeurs de modifier les mêmes données quel que soit le niveau d'isolement supérieur au niveau LECTURE NON VALIDEE. Dans la réalité, cette opération est rarement visible dans ArcGIS car le verrouillage en lecture d'un enregistrement est très bref ; les données ont à peine le temps de s'afficher que le déverrouillage a déjà été effectué. En pratique, les lecteurs peuvent uniquement bloquer les rédacteurs dans une application permettant d'ouvrir un curseur dans le SGBD, d'extraire une ligne à la fois et de faire défiler les résultats lors du traitement des données. Dans ce cas, Db2 et Informix commencent l'acquisition et le stockage des verrouillages lors du traitement des résultats.
PostgreSQL
Les rédacteurs bloquent les rédacteurs : dans PostgreSQL, la mise à jour d'un enregistrement s'avère impossible avant que la première transaction qui l'a modifié ne soit validée dans la base de données, ou annulée. Lorsque deux éditeurs tentent de mettre à jour ou de supprimer simultanément la même entité, le premier éditeur bloque les autres mises à jour effectuées sur cette ligne. Les autres éditeurs ne peuvent pas mettre à jour cette ligne tant que cet éditeur n'a pas enregistré (et, ce faisant, validé les modifications dans la base de données) ou interrompu la session de mise à jour sans enregistrer (ce qui a pour effet d'annuler toutes les mises à jour effectuées au cours de cette session).
Pendant le verrouillage de l'entité, le second éditeur tente de modifier la même entité. Sa session ArcMap attend le déverrouillage de l'entité et affiche un sablier indiquant qu'elle traite une action. Le sablier reste affiché jusqu'à ce que le premier éditeur enregistre ses modifications (les valide dans la base de données) ou interrompe la session de mise à jour sans enregistrer les modifications effectuées (annule toutes les mises à jour effectuées). Le second éditeur peut alors mettre à jour la table. (Cela signifie que les modifications du second éditeur remplacent celles du premier éditeur.)
Les rédacteurs ne bloquent pas les lecteurs : si vous utilisez le contrôle MVCC (MultiVersion Concurrency Control) de PostgreSQL, correspondant à la valeur par défaut et au comportement conseillé pour la base de données, les transactions qui accèdent à la base de données en écriture n'empêchent pas les lecteurs d'interroger cette dernière. Cela est valable, que vous utilisiez le niveau d'isolement par défaut LECTURE VALIDEE dans la base de données ou que vous définissiez le niveau d'isolement sur SERIALISABLE.
Les lecteurs ne bloquent pas les rédacteurs : indépendamment du niveau d'isolement défini dans la base de données, les lecteurs ne verrouillent pas les données.
SQL Server
A partir d'ArcGIS 10.4, les options de base de données SQL Server READ_COMMITTED_SNAPSHOT et ALLOW_SNAPSHOT_ISOLATION doivent être définies sur ON dans les géodatabases dans SQL Server et ArcGIS utilise le niveau d'isolement READ COMMITTED pour les transactions. Pour en savoir plus sur le niveau d'isolement LECTURE VALIDEE, consultez votre documentation SQL Server.
Les rédacteurs bloquent les rédacteurs : les rédacteurs bloquent d'autres rédacteurs dans SQL Server, à l'instar du fonctionnement dans Oracle.
Les rédacteurs ne bloquent pas les lecteurs : les lecteurs extraient la version validée de la ligne qui existait au démarrage de la déclaration ou de la transaction.
Les lecteurs ne bloquent pas les rédacteurs : lorsque des transactions s'exécutant sous un isolement de versionnement des lignes lisent des données, les opérations de lecture n'acquièrent pas de verrous partagés sur les données en cours de lecture et, par conséquent, n'empêchent pas les éditeurs de modifier les données. Ceci réduit également le nombre de verrous acquis et minimise le verrouillage des ressources. L'isolement de lecture validée avec l'aide du versionnement des lignes et l'isolement de capture d'écran sont conçus pour rendre cohérente la lecture des données versionnées au niveau des transactions ou au niveau des déclarations.
Prévention des problèmes d'accès instantané
Vous pouvez minimiser les problèmes d'accessibilité simultanée en suivant ces recommandations :
Concevoir des applications et des workflows en tenant compte des verrouillages
Les demandes en attente de déverrouillage sont souvent le résultat d'applications ou de workflows mal conçus. Lors du développement d'une application ou d'un workflow, assurez-vous que les verrouillages sont correctement organisés. Vous pouvez effectuer cette opération en standardisant la séquence des mises à jour dans toutes les tables. Ceci devrait empêcher tout risque d'arrêt fatal. Pour réduire la durée des verrouillages, il est recommandé de soumettre toutes les demandes de modification à la fin de chaque unité de logique d'application ou workflow exécutant une transaction.
Définir le niveau d'isolement approprié (Oracle, Db2, Informix)
Le niveau d'isolement affecte la durée de verrouillage des données d'une transaction. Plus le niveau d'isolement est élevé, plus la transaction verrouille les données. Plus la durée de verrouillage est longue, plus l'intégrité des données augmente, mais au détriment de l'accès simultané. Si votre application le permet, vous pouvez réduire le niveau d'isolement afin d'améliorer l'accès simultané.
Inscrire les données comme versionnées
Améliorez l'accessibilité simultanée en inscrivant les données comme versionnées. Si vous gérez des données avec des applications tierces, vous pouvez inscrire les données comme versionnées (traditionnelles) à l’aide de l’option permettant de déplacer les mises à jour vers la table de base. Cela permet aux applications tierces de voir les modifications appliquées à la version de géodatabase Par défaut. Cette méthode offre également la possibilité de mettre à jour et de gérer des versions des données aux applications ArcGIS et ArcObjects qui, autrement, seraient affectés par des problèmes d'accès simultané ou pourraient en provoquer. Lorsqu'un éditeur modifie une table versionnée, il n'applique aucun verrou, ce qui lui permet de modifier les données sans que les autres puissent intervenir.