Fonction de mise à jour partielle de colonne pour la persistance gérée par conteneur

La méthode de bean CMP (persistance gérée par conteneur) ejbStore stockait tous les attributs persistants du bean CMP dans la base de données, même en cas de modification d'un seul sous-ensemble de zones de ces attributs. Cette dégradation inutile des performances disparaît avec cette version du produit.

Remarque : Les beans entity ne sont pas pris en charge dans les modules EJB 3.0.
Pour les beans entity CMP Enterprise JavaBeans (EJB) 2.x, vous pouvez utiliser la fonction de mise à jour partielle afin d'indiquer la façon dont vous souhaitez mettre à jour les attributs persistants du bean CMP de la base de données. Cette fonction est disponible en tant qu'option de persistance de niveau bean, appelée PartialOperation, dans la règle de tentative d'accès configurée pour le bean. PartialOperation accepte l'une ou l'autre valeurs :
NONE
La mise à jour partielle est désactivée. Tous les attributs persistants du bean CMP sont stockés dans la base de données. Il s'agit de la valeur par défaut.
UPDATE_ONLY
Indique que la base de données n'est mise à jour qu'en cas de modification d'attributs persistants du bean CMP.
Pour plus d'informations sur la définition de mise à jour partielle, voir Définition d'une mise à jour partielle pour les beans CMP.

performance

Les mises à jour partielles accroissent les performances de plusieurs façons :
  • En réduisant le temps d'exécution des requêtes, puisque chaque requête ne contient qu'un sous-ensemble de colonnes. L'amélioration est plus importante pour les tables comportant un grand nombre de colonnes et d'index. Quand la table comporte de nombreux index, seuls ceux qui sont concernés par les colonnes modifiées doivent être mis à jour par la base de données dorsale.
  • En réduisant les entrées-sorties réseau puisque le volume de données à transmettre est moindre.
  • En économisant le temps de traitement pour les colonnes mappées significatives. Par exemple, si une colonne utilise des convertisseurs, des composeurs et des transformations pour injecter de façon partielle l'enregistrement en entrée.
  • En éliminant la mise en application inutile de déclencheurs UPDATE. Si une zone de bean CMP n'est pas modifiée, tout déclencheur ne dépendant que de la colonne correspondante n'est pas implémenté.
Bien qu'une mise à jour partielle améliore les performances, elle peut avoir une incidence négative inattendue sur les performances :
  • Si vous activez la mise à jour partielle au niveau d'un bean dont l'application modifie plusieurs combinaisons de colonnes durant le même laps de temps, la taille maximale des instructions préparées de la connexion est très rapidement atteinte. Par conséquent, certains descripteurs d'inscription sont évincés du cache en fonction de son utilisation la plus ancienne. Les préparations d'instructions se répètent, ce qui fait décroître les performances de toutes les fonctions CMP, et pas seulement celles de la méthode ejbStore().
  • Les modèles de requête de mise à jour partielle mises en cache dans le jeu de fonctions accroissent l'utilisation de la mémoire. L'accroissement est linéaire par rapport au nombre de zones du bean CMP pour lequel l'option de tentative d'accès en vue d'une mise à jour partielle e est activée.
  • L'option persistante PartialOperation, quand elle est combinée à l'option persistante Batch Update, a une incidence sur les performances de la mise à jour par lots car, dans ce cas, chaque requête partielle est différente. La génération dynamique d'une chaîne de requête de mise à jour partielle entraîne un coût au niveau du temps d'exécution. Puisque des fragments de requête sont stockés pour chaque colonne, le coût d'exécution lié à l'assemblage de ces fragments est linéaire, en fonction du nombre de zones de bean CMP modifiées.
  • Il existe des contrôles de condition pour chaque zone CMP, par exemple, pour inspecter les indicateurs de modification et exécuter les appels de méthode preparedStatement setXXX.

Considérations relatives à l'utilisation de la mise à jour partielle

Les gains de performances que vous espérez atteindre doivent être pondérés par rapport aux instances dans lesquelles une dégradation est possible. Pour prendre une décision, vous pouvez vous baser sur ces quelques conseils.
  • Une mise à jour partielle risque d'être préjudiciable aux performances d'une explication qui n'a qu'une petite table avec peu de colonnes, des types de données simples et pas de déclencheurs de mise à jour. Le coût d'assemblage dynamique de la requête partielle dépasse les gains de performance.
  • Une mise à jour partielle est bénéfique en présence d'un type de données complexe qui n'est pas souvent mis à jour. Parmi les types de données complexes, prenons par exemple un bean employé avec un attribut CMP photo de type BLOB ou VARGRAPHIC stocké dans un emplacement différent dans la mise en oeuvre du gestionnaire de base de données.
  • Une mise à jour partielle peut être bénéfique s'il existe plusieurs colonnes VARCHAR dont seulement quelques-unes sont mises à jour.
  • Il est préférable de ne pas recourir à la mise à jour partielle si l'application peut être en train de mettre à jour de façon aléatoire des combinaisons différentes de colonnes et si le nombre de colonnes pouvant être assignées (c'est-à-dire ne comportant pas de clé) est supérieur à 5. Cela a pour effet de générer des requêtes partielles différentes et de saturer rapidement le cache d'instructions préparées. En revanche, la mise à jour partielle combinée à l'augmentation du cache d'instructions pour assurer un nombre plus grand de requêtes est envisageable si le bean comporte peu de colonnes, quatre ou moins, avec des types de données complexes. Pour plus d'informations sur l'augmentation de la taille du cache d'instructions, consultez l'aide relative aux paramètres de source de données.
  • Une mise à jour partielle est intéressante quand des déclencheurs de mise à jour sont nécessaires sur un sous-ensemble de colonnes.
  • ne mise à jour partielle est intéressante quand la table contient plusieurs colonnes et index, et que seuls quelques-uns d'entre eux sont concernés par une mise à jour normale.

Restrictions

Par défaut, la mise à jour par lots des requêtes de mise à jour est désactivée pour tous les beans CMP dont l'option de mise à jour partielle est activée. En d'autres termes, une mise à jour partielle est prioritaire sur une mise à jour par lots. Cela ne concerne pas la mise à jour par lots de requêtes de suppression et d'insertion.

Les performances de mise à jour par lots quand les options de persistance de mise à jour par lots et de mise à jour partielle sont utilisées ensemble dans le même bean, car chaque requête partielle est différente. La propriété de JVM, -Dcom.ibm.ws.pm.grouppartialupdate=true permet de regrouper des requêtes de mise à jour partielle similaires dans une mise à jour par lots. Le regroupement de mises à jour partielles n'est utile que lorsqu'une transaction comporte plusieurs requêtes partielles de même forme. Autrement, le regroupement de mises à jour partielles pénalise les performances. Ce paramètre doit être utilisé avec précaution car il n'est pas activé au niveau du bean. Du fait qu'il s'applique à tous les beans dont la mise à jour partielle et la mise à jour par lots sont activées, vous devez vous assurer que la mise à jour par lots de requêtes partielles améliore vraiment les performances de tous les beans concernés par les deux types de mise à jour.

Pour définir la propriété de la JVM :

  1. Ouvrez le fichier server.xml.
  2. Changez la valeur de -Dcom.ibm.ws.pm.grouppartialupdate=true en -Dcom.ibm.ws.pm.grouppartialupdate=false.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_partupd
Nom du fichier : cejb_partupd.html