Vous devez souvent gérer les conflits possibles qui peuvent survenir lorsque plusieurs utilisateurs ou process chargent et tentent de modifier les mêmes entités en même temps. Le verrouillage des enregistrements est une méthodologie utilisée dans les bases de données relationnelles pour éviter les mises à jour incohérentes des données. Le concept consiste à verrouiller un enregistrement lors de la lecture afin qu'aucun autre process ne puisse le mettre à jour, ou bien à vérifier lors du stockage d'un enregistrement qu'un autre process ne l'a pas modifié depuis sa lecture. Le premier est appelé pessimistic record locking (verrouillage d'enregistrement pessimiste) et il garantit qu'un enregistrement modifié peut être écrit, en verrouillant les enregistrements pour les autres utilisateurs. Le dernier est appelé optimistic record locking (verrouillage d'enregistrements optimiste) et il ne garantit pas les privilèges d'écriture sur l'enregistrement au bénéfice d'une souplesse de décision des privilèges d'écriture uniquement si l'enregistrement doit être mis à jour. Dans le verrouillage d'enregistrement pessimiste, l'enregistrement est verrouillé même s'il n'est pas nécessaire de le mettre à jour. Dans le verrouillage d'enregistrement optimiste, la validité de la modification d'un enregistrement est décidée au moment de la mise à jour.

ORDA vous fournit deux mode de verrouillage d'entités :

• un mode "optimiste" automatique, adapté à la plupart des applications,
• un mode "pessimiste" permettant de verrouiller des entités avant leur accès.

Ce mécanisme automatique est basé sur le concept de "verrouillage optimiste" particulièrement adapté aux problèmatiques des applications web. Ce concept est caractérisé par les principes de fonctionnement suivants :

• Toutes les entités peuvent toujours être chargées en lecture-écriture ; il n'y a pas de "verroullage" a priori des entités.
• Chaque entité a un marqueur de verrouillage interne qui est incrémenté à chaque sauvegarde.
• Lorsqu'un utilisateur ou un process tente de sauvegarder une entité à l'aide de la méthode entity.save( ), 4D compare la valeur du marqueur de l'entité à enregistrer avec celle de l'entité trouvée dans les données (dans un cas de modification) :
  
  • Lorsque les valeurs correspondent, l'entité est enregistrée et la valeur du marqueur interne est incrémentée.
  • Lorsque les valeurs ne correspondent pas, cela signifie qu'un autre utilisateur a modifié cette entité entre-temps. La sauvegarde n'est pas effectuée et une erreur est renvoyée.

Le schéma suivant illustre le verrouillage optimiste :

1. Deux process chargent la même entité.

2. Le premier process modifie l'entité et valide la modification. La méthode entity.save( ) est appelée. Le moteur 4D compare automatiquement la valeur du marqueur interne de l'entité modifiée avec celle de l'entité stockée dans les données. Comme ils correspondent, l'entité est enregistrée et la valeur de son marqueur est incrémentée.

3. Le second process modifie également l'entité chargée et valide ses modifications. La méthode entity.save( ) est appelée. Etant donné que la valeur du marqueur de l'entité modifiée ne correspond pas à celle de l'entité stockée dans les données, l'enregistrement n'est pas effectué et une erreur est renvoyée.

Cela peut être également illustré par le code suivant :

Dans cet exemple, nous affectons à $person1 une référence à l'entité Person ayant une clé "1". Ensuite nous assignons une autre référence de la même entité à la variable $person2. En utilisant $person1, nous changeons le prénom de la personne et sauvegardons l'entité. Lorsque nous essayons de faire la même chose avec $person2, 4D vérifie que l'entité sur le disque est la même que lorsque la référence dans $person1 a été assignée la première fois. Comme elle n'est pas identique, false est renvoyé dans la propriété success et la seconde modification n'est pas enregistrée.

Lorsque cette situation se produit, vous pouvez, par exemple, recharger l'entité à partir du disque à l'aide de la méthode entity.reload( ) afin de pouvoir essayer à nouveau d'effectuer la modification. La méthode entity.save( ) propose également une option "autoMerged" pour sauvegarder l'entité dans les cas où les process ont modifié les attributs qui n'étaient pas les mêmes.

Note : Les marqueurs d'enregistrement ne sont pas utilisés dans les transactions car une seule copie d'un enregistrement existe dans ce contexte. Quel que soit le nombre d'entités qui référencent un enregistrement, la même copie est modifiée et les opérations de entity.save( ) ne généreront jamais d'erreurs de marqueurs.

Vous pouvez verrouiller et déverrouiller des entités à la demande, lors de l'accès aux données. Lorsqu'une entité est verrouillée par un process, elle est chargée en lecture/écriture dans ce process mais elle est verrouillée pour tous les autre process. L'entité peut uniquement être chargée en mode lecture seule dans ces process ; ses valeurs ne peuvent pas être éditées ou sauvegardées.

Cette fonctionnalité est basée sur deux méthodes de la classe Entity :

• entity.lock( )
• entity.unlock( )

Pour plus d'informations, veuillez vous reporter aux descriptions de ces méthodes.

L'utilisation simultanée de commandes du langage 4D "classic" et de méthodes ORDA pour verrouiller des enregistrements est basée sur les principes suivants :

• Un verrou posé par une commande 4D classic sur un enregistrement empêche ORDA de verrouiller toute entité correspondant à l'enregistrement.
• Un verrou posé par ORDA sur une entité empêche toute commande 4D de verrouiller l'enregistrement correspondant l'entité.

Ces principes sont illustrés dans le schéma suivant :

Les verrous de transaction s'appliquent également à la fois aux commandes 4D classic et aux méthodes ORDA. Dans une application multiprocess ou multi-utilisateurs, un verrou posé à l'intérieur d'une transaction sur un enregistrement par un commande 4D classic entraîne l'impossibilité pour tout autre process de verrouiller les entités liées à cet enregitrement (ou inversement) jusqu'à ce que la transaction soit validée ou annulée.

• Exemple de verrou posé par une commande classic :
  

• Exemple de verrou posé par une méthode ORDA :