Tous les systèmes de gestion de bases de données (SGBD) peuvent verrouiller des données afin de maintenir leur intégrité. Par exemple, lorsqu'un utilisateur entame la mise à jour de lignes, celles-ci se verrouillent pour empêcher un autre utilisateur de les modifier. Une fois la transaction terminée, les données sont déverrouillées.
Chaque SGBD présente une manière différente d'appliquer les verrouillages et d'interpréter les niveaux d'isolement. En outre, ArcGIS ne gère pas tous les types de SGBD de la même manière. En conséquence, les problèmes d'accès simultané éventuels en cas de modifications non versionnées varient légèrement selon les SGBD. Cette rubrique présente succinctement le fonctionnement de l'accès simultané et du verrouillage dans ArcGIS. Pour en savoir plus, consultez la documentation de votre SGBD.
ArcGIS et niveaux d'isolement
Lorsque vous modifiez une géodatabase Oracle, DB2 ou Informix dans une session de mise à jour non versionnée, les mêmes mécanismes de verrouillage de SGBD sous-jacents s'appliquent comme dans n'importe quelle application ; 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.
Lorsque vous modifiez une géodatabase SQL Server dans une session de mise à jour non versionnée, ArcGIS définit le niveau d'isolement sur LECTURE NON VALIDEE avant chaque transaction. Vous ne pouvez ni modifier, ni contourner cette procédure. Si vous appliquez un autre niveau d'isolement avant une transaction, ArcGIS rétablit le niveau sur LECTURE NON VALIDEE avant le début de la transaction.
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 utilisateurs essaient de modifier simultanément la même entité, celle-ci se verrouille lorsque le premier utilisateur termine une opération. Le verrouillage reste actif même si cet utilisateur modifie d'autres entités. L'entité reste verrouillée jusqu'à ce que l'utilisateur 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 utilisateur tente de modifier la même entité. Sa session ArcMap affiche alors un sablier indiquant qu'elle attend le déverrouillage de l'entité. Le sablier reste affiché jusqu'à ce que le verrouillage soit levé, lorsque le premier utilisateur 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 sablier disparaît alors de l'écran du second utilisateur ; son opération de mise à jour peut alors être effectuée. (Remarque : les mises à jour effectuées par le second utilisateur écrasent celles du premier.)
Ce problème de verrouillage peut également survenir simultanément entre deux utilisateurs dans les cas suivants :
- Les deux utilisateurs ouvrent simultanément une session de mise à jour
- Les utilisateurs ont modifié des lignes dans leur session de mise à jour actuelle.
- Chaque utilisateur tente de modifier une ligne qui a déjà été modifiée par l'autre utilisateur.
Le premier des utilisateurs 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 utilisateur tente de modifier une ligne verrouillée par le premier utilisateur, une situation connue sous le terme d'arrêt fatal survient car les deux utilisateurs se bloquent mutuellement. Le SGBD choisit rapidement d'annuler l'une des transactions afin que l'autre puisse continuer. L'utilisateur 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 utilisateurs qui modifient des informations dans la base de données n'empêchent pas les autres utilisateurs de lire ces mêmes informations, indépendamment du niveau d'isolement. Pour les utilisateurs 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 utilisateurs qui lisent la base de données n'empêchent pas les autres utilisateurs 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, reportez-vous aux explications de la section "Oracle".
Les rédacteurs bloquent les lecteurs : dans DB2 et Informix, les rédacteurs empêchent d'autres utilisateurs 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érieur, 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 un autre utilisateur ajoute 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 un autre utilisateur tente 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 un autre utilisateur identifie 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 utilisateurs 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 utilisateurs tentent de modifier simultanément la même entité, le premier utilisateur bloque les autres mises à jour effectuées sur cette ligne. Les autres utilisateurs ne peuvent pas mettre à jour cette ligne tant que cet utilisateur 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 utilisateur tente de modifier la même entité. Sa session ArcMap affiche alors un sablier indiquant qu'elle attend le déverrouillage de l'entité. Le sablier reste affiché jusqu'à ce que le premier utilisateur 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 sablier disparaît alors de l'écran du second utilisateur ; son opération de mise à jour peut désormais être effectuée. (Remarque : les mises à jour effectuées par le second utilisateur écrasent celles du premier.)
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 utilisateur 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
ArcGIS définit le niveau d'isolement sur LECTURE NON VALIDEE avant chaque transaction dans une géodatabase SQL Server. Les sections suivantes décrivent certains problèmes d'accès simultané pouvant survenir dans ArcGIS. Pour en savoir plus sur le niveau d'isolement LECTURE NON 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. Pour en savoir plus, reportez-vous aux explications de la section "Oracle".
Les rédacteurs ne bloquent pas les lecteurs : ArcGIS définissant le niveau d'isolement sur LECTURE NON VALIDEE avant chaque transaction, les rédacteurs ne bloquent pas les lecteurs dans les géodatabases SQL Server. Cependant, si certains utilisateurs modifient des données, tandis que d'autres les lisent, ces derniers peuvent lire des données qui ont été modifiées, mais pas encore validées. Il s'agit d'une lecture non validée avec laquelle une requête peut entraîner les résultats suivants :
- Les valeurs de données sont inexactes
- Aucune donnée n'est renvoyée alors que des données existent
- Des données dupliquées sont renvoyées alors qu'il n'existe aucune donnée
Les lecteurs ne bloquent pas les rédacteurs : ArcGIS définissant le niveau d'isolement sur LECTURE NON VALIDEE avant chaque transaction, les lecteurs ne bloquent pas les rédacteurs dans les géodatabases SQL Server.
Prévention des problèmes d'accès instantané
Heureusement, plusieurs méthodes permettent de réduire les problèmes d'accès instantané :
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 à l'aide de l'option permettant de déplacer les mises à jour vers la table de base. Cela permet aux utilisateurs de continuer à gérer des données avec les applications qui n'utilisent pas ArcGIS, mais il offre la possibilité de mettre à jour et de gérer des versions des données aux utilisateurs d'ArcGIS et d'ArcObjects qui, autrement, seraient affectés par des problèmes d'accès simultané ou pourraient en provoquer. Lorsqu'un utilisateur modifie une version, il n'applique aucun verrouillage, ce qui lui permet de modifier les données sans que les autres utilisateurs puissent intervenir.
Le verrouillage des bases de données est un sujet complexe. En outre, chaque SGBD verrouille les données de façon différente. 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.