Considérations liées à la conception d'applications de chargeur à écriture différée

Lorsque vous implémentez un chargeur à écriture différée, vous devez prendre en compte plusieurs points tels que les contraintes d'intégrité, le comportement de verrouillage et les performances.

Considérations liées à la conception d'applications

L'activation de l'écriture différée est une opération simple, mais la création d'une application devant utiliser l'écriture différée requiert une attention particulière. Sans écriture différée, la transaction ObjectGrid encadre la transaction dorsale. La transaction ObjectGrid démarre avant la transaction dorsale et se termine après celle-ci.

Lorsque la prise en charge de l'écriture différée est activée, la transaction ObjectGrid se termine avant le début de la transaction dorsale. La transaction ObjectGrid et la transaction dorsale sont dissociées.

Contraintes d'intégrité référentielle

Chaque mappe de sauvegarde configurée avec écriture différée dispose de sa propre unité d'exécution d'écriture différée pour envoyer les données vers le système dorsal. Les données mises à jour dans les différentes mappes d'une transaction ObjectGrid sont mises à jour dans le système dorsal via différentes transactions dorsales. Par exemple, la transaction T1 met à jour la clé key1 dans la mappe Map1 et la clé key2 dans la mappe Map2. La clé key1 mise à jour dans la mappe Map1 est actualisée vers le système dorsal dans une transaction expéditrice et la clé key2 actualisée dans la mappe Map2 l'est dans une autre transaction expéditrice ; cette mise à jour vers le dorsal est effectuée dans deux unités d'exécution différentes, toutes deux en écriture différée. Si les données stockées dans Map1 et Map2 ont des liens, tels que des contraintes de clé externe dans le système dorsal, les mises à jour sont susceptibles d'échouer.

Lors de la conception de contraintes d'intégrité référentielle dans votre base de données dorsale, vérifiez que les mises à jour désordonnées sont autorisées.

Verrouillage d'une mappe de files d'attente

Le comportement des transactions en matière de verrouillage constitue une autre différence notable. La grille d'objets prend en charge trois stratégies de verrouillage différentes : PESSIMISTIC, OPTIMISITIC et NONE. Les mappes de files d'attente à écriture différée utilisent la stratégie de verrouillage pessimiste, quelle que soit la stratégie de verrouillage configurée pour leur mappe de sauvegarde. Deux types différents d'opérations permettant d'acquérir un verrou sur la mappe de files d'attente existent :
  • Lorsqu'une transaction ObjectGrid est validée ou qu'un vidage (de mappe ou de session) se produit, la transaction lit la clé de la mappe de files d'attente et place un verrou S sur la clé.
  • Lorsqu'une transaction ObjectGrid est validée, elle tente de mettre à niveau le verrou S vers un verrou X sur la clé.
Ce comportement de mappe de files d'attente supplémentaire vous permet de voir quelques différences dans le comportement de verrouillage.
  • Si la mappe des utilisateurs est configurée en tant que stratégie de verrouillage de type pessimiste, la différence de comportement est peu importante. A chaque appel d'un vidage ou d'une validation, un verrou S est placé sur la même clé de la mappe de files d'attente. Au moment de la validation, un verrou X est acquis pour la clé dans la mappe de l'utilisateur, mais également pour la clé dans la mappe de files d'attente.
  • Si la mappe des utilisateurs est configurée en tant que stratégie de verrouillage de type OPTIMISTIC ou NONE, la transaction utilisateur suit le modèle de la stratégie de verrouillage de type PESSIMISTIC. A chaque appel d'un vidage ou d'une validation, un verrou S est acquis pour la même clé de la mappe de files d'attente. Au moment de la validation, un verrou X est acquis pour la clé dans la mappe de files d'attente utilisant la même transaction.

Nouvelles tentatives de transaction du chargeur

ObjectGrid ne prend pas en charge les transactions à 2 phases ou transactions XA. L'unité d'exécution à écriture différée supprime les enregistrements de la mappe de files d'attente et met à jour les enregistrements dans le système dorsal. En cas d'échec du serveur au milieu de la transaction, certaines mises à jour dorsales risquent d'être perdues.

Le chargeur à écriture différée tente automatiquement d'écrire à nouveau les transactions ayant échoué et envoie une LogSequence en attente de validation au système dorsal pour éviter toute perte de données. Pour que l'exécution de cette action soit possible, le chargeur doit être idempotent, ce qui signifie que lorsque Loader.batchUpdate(TxId, LogSequence) est appelé deux fois avec la même valeur, le résultat est le même que s'il était appelé une fois. Les implémentations du chargeur doivent implémenter l'interface RetryableLoader pour activer cette fonction. Pour plus de détails, consultez la documentation relative à l'API.

Considérations liées aux performances de la mise en cache à écriture différée

La prise en charge de la mise en cache à écriture différée améliore le temps de réponse en supprimant la mise à jour du chargeur de la transaction. Elle augmente également la capacité de traitement de la base de données, car les mises à jour de base de données sont combinées. Il est important de comprendre le temps système supplémentaire généré par l'unité d'exécution à écriture différée, qui permet de retirer les données de la mappe de files d'attente et de les insérer dans le chargeur.

Le nombre maximal de mises à jour ou leur durée maximale doivent être ajustés en fonction des modèles d'utilisation et de l'environnement attendus. Si la valeur associée à ce nombre ou à cette durée est trop faible, le temps système supplémentaire nécessaire à l'unité d'exécution risque d'être supérieur aux avantages. Le choix d'une valeur élevée pour ces deux paramètres permet d'améliorer l'utilisation de la mémoire lors de la mise en file d'attente des données et retarder le moment de péremption des enregistrements de la base de données.

Pour des performances optimales, réglez les paramètres d'écriture différée en fonction des facteurs suivants :
  • Rapport entre les transactions de lecture et d'écriture
  • Fréquence identique de mise à jour des enregistrements
  • Temps d'attente de la mise à jour de la base de données