Transactions et planificateurs

Le planificateur exécute une tâche dans une seule transaction globale par défaut. Vous pouvez utiliser la qualité de service QOS_ONLYONCE ou QOS_ATLEASTONCE pour spécifier si la tâche s'exécute sur une seule unité de travail une seule fois ou en tant que transactions indépendantes.

Comportement d'une transaction lors de l'exécution d'une tâche

Puisque le planificateur exécute une tâche dans une seule transaction globale par défaut, la transaction est ouverte jusqu'à ce que l'exécution de la tâche aboutisse ou échoue. Les ressources impliquées dans cette transaction sont sujettes à divers délais d'inactivité et l'unité d'exécution de la tâche peut être jugée comme bloquée si la tâche s'exécute sur une longue période allant de plusieurs minutes à plusieurs heures.

QOS_ONLYONCE

Les tâches planifiées ne s'exécutent qu'une seule fois avec succès lors de l'utilisation de la qualité de service QOS_ONLYONCE. Cette action s'effectue au moyen du regroupement de tous les travaux effectués dans la tâche sous la forme d'une unité de travail unique. Lors du déclenchement de chaque tâche, les événements suivants se produisent dans un contexte transactionnel global unique :
  1. Le contexte de l'application qui a créé la tâche s'applique à l'unité d'exécution.
  2. Un contexte transactionnel global est lancé.
  3. L'heure de déclenchement et l'heure de démarrage suivantes sont calculées à l'aide du bean UserCalendar ou de DefaultUserCalendar.
    Important : Si la méthode TaskInfo.setTaskExcecutionOptions est utilisée avec l'option TaskInfo.EXECUTION_DELAYEDUPDATE, cette étape s'effectue une fois l'enregistrement mis à jour.
  4. L'enregistrement de tâche de base de données est mis à jour dans la base de données avec l'état de la tâche suivante ou supprimé si la tâche est terminée et que le paramètre de purge automatique de la tâche a pour valeur true.
  5. L'enregistrement de tâche de base de données est mis à jour dans la base de données avec l'état de la tâche suivante ou supprimé si la tâche est terminée et que le paramètre de purge automatique de la tâche a pour valeur true. Si l'option EXECUTION_DELAYEDUPDATE est utilisée, la base de données ne reflète pas l'état suivant de la tâche, mais l'état courant avec l'état défini TaskStatus.RUNNING.
  6. Si le bean NotificationSink est défini, une notification FIRING est émise.
  7. L'objet BeanTaskInfo ou MessageTaskInfo démarre.
  8. Si la tâche échoue et que le bean NotificationSink est défini, une notification FIRE_FAILED est émise au niveau d'une transaction distincte.
  9. Si le bean NotificationSink de la tâche est défini, les diverses notifications sont émises, selon les besoins.
  10. Si l'option EXECUTION_DELAYEDUPDATE est utilisée pour la tâche, la base de données est mise à jour une seconde fois avec le nouvel état de la tâche.
  11. La transaction globale est validée.
Dans la mesure où tous les événements appartenant à une tâche sont exécutés dans un contexte transactionnel global unique, vous devez prendre en considération les éléments suivants afin d'éviter des erreurs liées à la transaction :
  • Chaque ressource participant dans une transaction de la tâche doit prendre en charge XA à 2 phases.

    Il s'agit de la source de données JDBC (Java™ Database Connectivity) configurée pour le planificateur, de tous les services JMS (Java Messaging Service) utilisés par les objets MessageTaskInfo et de toutes les ressources utilisées dans des beans UserCalendar, TaskHandler ou NotificationSink dont le paramètre de transaction a pour valeur "Requis".

  • Une ressource peut comporter une phase unique si le support de dernier participant est activé pour l'application qui a créé la transaction. Activez le support de dernier participant à l'aide d'un outil d'assemblage. Vous pouvez aussi activer le support du dernier participant avec la console d'administration. Pour plus d'informations, reportez-vous à la rubrique Paramètres d'extension du support du dernier participant.

Toutes les exceptions imprévues sont consignées dans le journal des activités et tous les événements participant à la transaction globale de la tâche sont annulés. Il s'agit notamment des modifications apportées à l'enregistrement de base de données de la tâche, qui force la nouvelle exécution de la tâche lorsque le démon de planification interroge la base de données au cours du cycle d'interrogation suivant. Les beans UserCalendar, TaskHandler et NotificationSink peuvent choisir de ne pas participer à la transaction globale en configurant le paramètre de transaction du bean à la valeur "Nouvel adaptateur requis".

QOS_ATLEASTONCE

Les tâches planifiées qui utilisent la qualité de service QOS_ATLEASTONCE ne disposent pas d'un contexte transactionnel unique. Dans ce cas, chaque calcul du planning, notification d'événement et mise à jour de la base de données se produit dans une transaction indépendante :
  1. Le contexte de l'application qui a créé la tâche s'applique à l'unité d'exécution.
  2. L'enregistrement de base de données de la tâche est mis à jour avec l'état EN COURS D'EXECUTION de la tâche.
  3. Les beans UserCalendar et NotificationSink sont appelés.
  4. BeanTaskInfo ou MessageTaskInfo est démarré.
  5. Les notifications de résultats sont envoyées.
  6. La base de données est mise à jour avec l'état suivant de la tâche, si cette dernière n'a pas été modifiée depuis l'écriture de l'état EN COURS D'EXECUTION.

Si un incident se produit après l'écriture de l'état EN COURS D'EXECUTION dans la base de données et avant que le résultat ne soit écrit, il se peut que la tâche s'exécute plus d'une fois.

Si vous utilisez QOS_ATLEASTONCE, tous les beans NotificationSink, UserCalendar et TaskHandler ne doivent pas imposer de transaction (TX_MANDATORY), du fait qu'aucune transaction globale n'est disponible lorsque la tâche s'exécute. Les composants d'EJB utilisent une transaction gérée par conteneur "Requis" ou "Nouvel adaptateur requis" ou une transaction gérée par bean.

Comportement d'une transaction lors de l'utilisation des méthodes d'API du planificateur ou des opérations MBean WASScheduler

Toutes les méthodes d'interface de planification participent à un contexte transactionnel global unique. Si l'unité d'exécution contient déjà un contexte transactionnel global lorsque les méthodes create(), suspend(), resume(), cancel() et purge() sont exécutées, la transaction globale existante est alors utilisée. Dans le cas contraire, une nouvelle transaction globale est lancée.

Si la méthode participe à la transaction globale de l'appelant et qu'une erreur imprévue se produit, la transaction est marquée pour être annulée. S'il s'agit d'une exception déclarée, celle-ci est émise de nouveau à l'appelant et il appartient à l'appelant de valider ou d'annuler la transaction.

Si la méthode démarre sa propre transaction globale et qu'une exception se produit, la transaction est annulée et l'exception est de nouveau émise à l'appelant.


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