Gestion des unités d'exécution et Spring Framework

Utilisez les informations des sections qui suivent pour éviter les problèmes possibles avec les unités d'exécution non gérées.

Unités d'exécution non gérées

N'utilisez pas de scénario pouvant conduire à créer des unités d'exécution non gérées, pour les raisons suivantes :
  • Le serveur d'applications ne reconnaît pas les unités d'exécution non gérées.
  • Les unités d'exécution non gérées n'ont pas accès aux informations contextuelles de Java™ EE.
  • Les unités d'exécution non gérées peuvent utiliser des ressources sans être contrôlées par le serveur d'applications.
  • Les unités d'exécution non gérées peuvent avoir un effet néfaste sur les fonctions du serveur d'applications, par exemple sur l'arrêt ou la récupération de ressources après un incident.
  • L'administrateur ne peut pas contrôler le nombre des unités d'exécution non gérées ou leur utilisation des ressources.
Les exemples suivants décrivent quelques-uns des scénarios à éviter :
  • registerShutdownHook

    Evitez d'utiliser la classe Spring Framework AbstractApplicationContext et ses sous-classes. Ces classes comprennent la méthode publique registerShutdownHook, qui crée une unité d'exécution et l'enregistre avec la machine virtuelle Java (JVM) pour qu'elle s'exécute à l'arrêt du système afin de fermer le contexte d'application. Une application peut également utiliser les notifications de cycle de vie reçues du conteneur du serveur d'applications pour appeler la méthode de fermeture explicitement dans le contexte d'application.

  • WeakReferenceMonitor

    Spring Framework fournit des classes usuelles permettant un développement simplifié des composants EJB. Toutefois, ces classes déploient une unité d'exécution non gérée que l'objet WeakReferenceMonitor utilise pour le nettoyage.

Création de pools d'unités d'exécution

WebSphere Application Server prend en charge l'utilisation de la classe Spring Framework WorkManagerTaskExecutor pour exécuter des travaux en mode asynchrone.

La classe WorkManagerTaskExecutor utilise des pools d'unités d'exécution gérés par le serveur d'applications et délègue des travaux à une instance configurée de l'objet WorkManager. Pour plus d'informations sur la configuration d'un gestionnaire de travaux, voir les rubriques connexes.

N'utilisez pas les autres classes TaskExecutor fournies avec Spring Framework car elles peuvent démarrer des unités d'exécution non gérées.

Vous pouvez utiliser le nom JNDI (Java Naming and Directory Interface) du gestionnaire de travaux configuré pour la propriété workManagerName afin de définir une instance de l'objet WorkManagerTaskExecutor dans le fichier de configuration de Spring. L'exemple suivant utilise le nom JNDI de l'objet DefaultWorkManager dans le serveur d'applications, c'est-à-dire wm/default :
<bean id="myTaskExecutor" 
  class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
  <property name="workManagerName" value="wm/default" />
</bean>

Planification

Vous pouvez utiliser le module de planification CommonJ WorkManager de Spring Framework pour utiliser des unités d'exécution gérées par le serveur d'applications. Evitez d'utiliser d'autres modules du JDK (Java SE Development Kit, comme le planificateur Quartz ou Timer, car ils peuvent démarrer des unités d'exécution non gérées.


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=cspr_design
Nom du fichier : cspr_design.html