Verrouillage optimiste

Le verrouillage optimiste vous permet de réduire le niveau d'isolation de sorte à verrouiller un nombre plus restreint de ressources de la base de données. Il permet à un plus grand nombre d'applications de s'exécuter simultanément et augmente potentiellement le rendement de vos applications.

Important : Par défaut, la plus grande partie du code HCL Commerce exécute des requêtes de base de données à des niveaux d'isolement spécifiés qui se trouvent dans des tolérances de sécurité pour ces requêtes individuelles. Vous pouvez assurer des performances optimales de votre site en définissant le niveau d'isolement par défaut pour WebSphere Application Server sur Cursor Stability. Pour plus d'informations sur la définition du niveau d'isolement par défaut pour WebSphere Application Server, consultez Changing the default isolation level for non-CMP applications and describing how to do so using a new custom property webSphereDefaultIsolationLevel.

Pour se protéger de problèmes potentiels d'intégrité de la base de données, l'implémentation d'un verrouillage optimiste doit veiller à ce que de tels problèmes ne puissent pas survenir. L'implémentation de HCL Commerce utilise une colonne de prédicat optimiste pour chaque table de la base de données HCL Commerce OPTCOUNTER. Ceci permet de s'assurer qu'à chaque modification de la base de données, le prédicat optimiste puisse être :

Mis à jour avec une nouvelle valeur
Vérifié en cas de modification

De cette manière, l'implémentation peut garantir qu'une ligne de la base de données n'a pas été modifiée entre le moment de sa lecture et celui de son écriture, de sorte à protéger l'intégrité de la base.

Des inconvénients peuvent aussi accompagner ce nouveau degré de liberté permis par le verrouillage optimiste (moins de verrous sur la base de données et pour un laps de temps plus court).

Le verrouillage pessimiste entraîne la prévention des problèmes associés au verrouillage optimiste par le placement de verrous sur la base de données. En d'autres termes, le verrouillage pessimiste présume que des collisions surviendront dans la base de données et prend les précautions requises pour les éviter. Une stratégie de verrouillage pessimiste protège l'intégrité de la base de données en verrouillant les ressources de la base de données pendant toute la durée de la transaction, du début à la fin. Pendant cette période, aucune autre transaction ne peut accéder à ces mêmes ressources, celles-ci étant verrouillées. Cette stratégie débouche sur des délais d'attente plus longs pour des transactions plus nombreuses. Il est aussi possible que ces transactions dépassent alors leur délai imparti ou se retrouvent dans une situation d'interblocage.

Une optimistic locking strategy peut améliorer l'exécution de l'application en réduisant le créneau pendant lequel ces conséquences néfastes peuvent survenir. En même temps, elle s'expose à des collisions lorsque deux transactions, voire plus, tentent de mettre à jour la même ligne dans la base de données. Lorsque cette situation survient sous une stratégie de verrouillage optimiste, une rétrogression (ou un échec) d'une ou de toutes les transactions peut se produire.

HCL Commerce utilise un schéma de verrouillage optimiste qui permet de réduire le niveau d'isolement des transactions de la base de données de lecture reproductible à lecture validée. Avec ce schéma, les lignes de base de données qui ne sont normalement pas accédées simultanément ne sont pas verrouillées avec prévision de mise à jour lorsqu'elles sont lues. A la place du verrouillage, lorsqu'une mise à jour est finalement effectuée, la ligne est vérifiée pour s'assurer qu'elle n'a pas été mise à jour simultanément depuis sa lecture. Si c'est le cas, la transaction est ramenée à son état précédent et la commande peut être relancée depuis le début dans une nouvelle transaction, le cas échéant. Ce schéma sans exécution de mises à jour simultanées améliore les performances puisque le processus relativement coûteux en ressources d'obtention des verrouillages de base de données avec prévision de mise à jour est évité. Par ailleurs, dans les opérations au cours desquelles des mises à jour simultanées sont susceptibles de se produire, le verrouillage pessimiste, avec lequel des verrouillages avec prévision de mise à jour sont obtenus à la lecture de la ligne, est toujours utilisé, ce qui évite le processus plus coûteux d'annulation puis de redémarrage à partir du début dans une nouvelle transaction.

Pour plus d'informations, voir OptCounterInfo.

Pour que le verrouillage optimiste fonctionne correctement, chaque requête qui met à jour une ligne de table de base de données doit incrémenter la valeur de la colonne OPTCOUNTER ou la réinitaliser à 1 lorsque la valeur en cours est 32767. Le serveur HCL Commerce utilise cette technique. Toutefois, si les lignes de table de base de données sont mises à jour par d'autres procédures de code ou manuelles qui ne mettent pas à jour les valeurs de colonne OPTCOUNTER, les déclencheurs de base de données définis dans les fichiers de schéma utilities_root/schema/9.0.0.0/db_type/wcs.perf.trigger.sql garantissent que les valeurs de colonne OPTCOUNTER sont correctement incrémentées.

La couche service de données prend en charge un mécanisme dénommé contrôle d'accès concurrents optimiste dont la fonction et l'implémentation sont similaires à celles du verrouillage optimiste utilisé par les EJB dans HCL Commerce. Ce mécanisme est implémenté par défaut pour la plupart des tables de HCL Commerce en vue d'optimiser les performances. La modification de l'utilisation de ce mécanisme n'est pas recommandée.

Lorsque vous ajoutez des tables au schéma HCL Commerce, vous avez la possibilité d'appliquer à celles-ci la fonctionnalité de contrôle d'accès concurrents optimiste. Vous devez alors définir une colonne de collision intitulée OPTCOUNTER dans la définition de la table. La colonne OPTCOUNTER doit être de type SMALLINT ou INTEGER. La couche service de données met à jour automatiquement le compteur de la colonne de collision. Lorsqu'une collision survient au cours de la sauvegarde, une exception est renvoyée.

Remarque : Si le code personnalisé utilise le bean d'accès pour mettre à jour les tables liées à la commande et reçoit une exception de verrouillage optimiste, il est possible que cela soit dû au fait que le même enregistrement a été modifié par une procédure stockée prête à l'emploi dans la même transaction. Pour résoudre le problème, le code personnalisé doit d'abord appeler le gestionnaire d'entités pour actualiser l'entité du bean d'accès avant de le mettre à jour.

Remarque : Il est possible que le bean d'entité détaché du gestionnaire d'entités entraîne l'utilisation du code personnalisé par le bean d'accès pour mettre à jour une table de base de données, mais cette opération n'est pas conservée dans la base de données. Vous pouvez appeler le gestionnaire d'entités pour actualiser l'entité afin de confirmer qu'il s'agit du problème. Si le bean d'accès est détaché, le gestionnaire d'entités émet une exception indiquant que l'entité est détachée lors de l'appel de l'actualisation. Le code personnalisé doit appeler la méthode de fusion du gestionnaire d'entités pour rattacher le bean d'accès au gestionnaire d'entités et ainsi résoudre ce problème.

Options de configuration de MemberLock

En raison de blocages de base de données, les clients peuvent voir des messages d'erreur lors de la tentative de connexion. Vous devez modifier votre code personnalisé pour empêcher l'utilisation de UserAccessBean. Utilisez plutôt userDataBean ou les beans fournis par la méthode WCDataCache.newUserAccessBean (le cas échéant). Vous devez également activer la sérialisation à l'aide des paramètres HitAndMiss , qui sont expliqués ci-dessous. Enfin, lors de l'activation de la sérialisation en opération, vous devez exécuter des validations de performances et de test fonctionnel à l'aide de charges de tâches à volume élevé réalistes.

Toutes les demandes d'une session utilisateur spécifique sont envoyées au même serveur lorsque l'affinité de session est activée. Les blocages peuvent parfois être évités en sérialisant toutes les unités d'exécution qui lisent un EJB utilisateur spécifique (à l'exception de l'utilisateur générique, avec l'ID -1002).

En faisant l'acquisition de verrous Java, le cache de données HCL Commerce est utilisé pour obtenir l'entrée d'objets EJB utilisateur, que le cache de données soit activé ou non. Pour tirer parti de cette fonction, le code personnalisé, tel qu'une commande de connexion personnalisée, vous devez éviter d'utiliser la classe UserAccessBean directement et utiliser à la place la classe UserDataBean, ou WCDataCache.newUserAccessBean, si disponible.

Cette fonction de sérialisation peut être activée ou désactivée et est désactivée par défaut. La fonctionnalité peut être activée en ajoutant l'option suivante à la balise <InstanceProperties> du fichier de configuration de l'instance wc-server.xml :

<OptimisticLockingSelectForUpdate
com.ibm.commerce.user.beans.MemberLock.HitAndMiss="enabled"
/>

La configuration ci-dessus entraîne l'obtention du verrou Java par le cache de données sur les caches, le cache trouvé et le cache manqué. Un autre paramètre peut être fourni pour améliorer les accès concordants, mais avec beaucoup moins de sécurité contre les blocages probables :

<OptimisticLockingSelectForUpdate
com.ibm.commerce.user.beans.MemberLock.Miss="enabled"
/>

Le verrou Java n'est obtenu que s'il y a un cache manqué avec la configuration ci-dessus.

La sérialisation des unités d'exécution peut entraîner le blocage des unités d'exécution si les unités d'exécution impliquées conservent des ressources, telles que des verrous de base de données. Le verrouillage Java proposé dans ce correctif inclut des protections.

La première fonction de sécurité est que tout au long d'une transaction de base de données, chaque unité d'exécution attendra uniquement les verrous jusqu'à 10 secondes. Si le seuil de 10 secondes est dépassé, cette unité d'exécution ne pourra pas atteindre les verrous pour la transaction restante et l'erreur initiale de blocage ou d'accès concurrents optimiste peut se produire.

La deuxième fonction de sécurité est que les verrous Java sont automatiquement libérés après avoir été retenus pendant 60 secondes. En raison de ce délai d'expiration de 60 secondes, une autre unité d'exécution peut obtenir le verrou et s'exécuter simultanément avec l'unité d'exécution qui a maintenu le verrou avant son expiration, et le blocage initial ou l'exception d'accès concurrent optimiste peut se produire.

La fonctionnalité peut être activée en ajoutant l'option suivante à la balise <InstanceProperties> du fichier de configuration de l'instance wc-server.xml :

<com.ibm.commerce.user.beans.MemberLock threshold="10"
timeout="60" />