Verrouillage de lignes partagées ESQL et blocs ATOMIC

Vous pouvez utiliser des lignes partagées ESQL dans un flux de messages pour partager des données entre des unités d'exécution, afin que toutes les unités d'exécution puissent lire et mettre à jour des données écrites par d'autres unités d'exécution. Vous pouvez également utiliser des lignes partagées ESQL dans un flux de messages pour partager des données dans le temps, ce qui signifie que les messages qui passent par un flux peuvent enregistrer des données pour un accès ultérieur.

A propos de cette tâche

Un exemple d'utilisation de lignes partagées ESQL est la mise en cache du contenu de la base de données dans des variables partagées pour des raisons de performances. Dans ce scénario, qui utilise les deux types de partage de données, la première unité d'exécution charge les données dans le cache pour qu'elles soient utilisées par toutes les unités d'exécution, et à partir de ce point, aucun accès à la base de données n'est requis.

Lorsque vous utilisez des variables partagées, vous devez vous assurer que l'accès aux données est synchronisé afin d'éviter les problèmes causés par l'accès de plusieurs unités d'exécution aux mêmes données. Par exemple, si la mise en cache de la base de données se compose de plusieurs éléments, vous devez empêcher les unités d'exécution de tenter de lire les données alors qu'elles sont en cours de mise à jour.

IBM® App Connect Enterprise prend en charge une implémentation à variables partagées, dans laquelle le serveur d'intégration dispose de deux niveaux de verrouillage afin d'éviter les conflits. Le premier niveau se trouve au niveau de la variable partagée elle-même, et le deuxième niveau est le mot clé ATOMIC dans ESQL, que vous pouvez utiliser pour synchroniser les unités d'exécution de flux. Ces deux mécanismes utilisent des verrous en lecture-écriture au lieu de mutexes, afin de permettre une meilleure mise à l'échelle dans les solutions à unités d'exécution multiples.

Les verrous en lecture-écriture offrent les avantages suivants lorsqu'ils sont utilisés avec des lignes partagées:

  1. La capacité de plusieurs lecteurs à lire les données sans les bloquer, ce qui améliore l'échelle du scénario de mise en cache et peut améliorer les performances.
  2. Capacité d'un seul programme d'écriture à bloquer tous les lecteurs, ce qui permet de charger le cache sans que les lecteurs voient des mises à jour partielles. Cette approche peut être bénéfique en termes de fiabilité.
Lorsqu'une unité d'exécution est capable de prendre plusieurs verrous (en lecture et en écriture), il est possible que chacune des deux unités d'exécution maintende un verrou en attendant le verrou détenu par l'autre unité d'exécution. L'exemple suivant implique deux unités d'exécution prenant des verrous dans l'ordre inverse, ce qui entraîne un blocage:

thread 1 takes write lock A
thread 2 takes write lock B
thread 1 tries to take read lock B and blocks because thread 2 is holding the write lock
thread 2 tries to take read lock A and blocks because thread 1 is holding the write lock

Comme ces interblocages peuvent être difficiles à détecter, le code de verrouillage des variables partagées prend des mesures pour les empêcher de se produire, en limitant les verrous qui peuvent être utilisés lorsque d'autres verrous sont maintenus. Par exemple, l'appel de PROPAGATE dans un bloc ATOMIC entraîne l'émission d'une exception BIP2526 .

Pour des exemples d'utilisation de lignes partagées avec et sans blocs ATOMIC, voir les rubriques suivantes:
Pour plus d'informations sur l'utilisation d'ESQL, voir les rubriques suivantes: