[z/OS]

Travail en cours et mode abandon supposé

Le mode d'abandon supposé est activé lorsqu'une défaillance se produit avant que la transaction répartie ne commence la validation.

Si vous avez une transaction répartie qui s'étend sur plusieurs serveurs, des verrous transactionnels peuvent être maintenus par des gestionnaires de ressource impliqués dans ce travail. Lorsqu'une défaillance survient avant que la transaction répartie n'ait commencé à valider, le produit et les gestionnaires de ressources passent en mode d'abandon supposé. Dans ce mode, les gestionnaires de ressources annulent la transaction.
  • L'effet d'une défaillance de serveur ou d'un échec de communication dépendra du serveur sur lequel le travail est exécuté au moment de l'incident.
  • Une expiration du service OTS peut s'avérer nécessaire pour annuler les branches subordonnées de l'arbre de transactions réparties.
Exemple : un client Web B serveur dirigeant une bean session sur le même serveur en est une bonne illustration. Cette bean session bean a effectué du travail pour des beans entity dans les serveurs C et D. Tous les serveurs sont impliqués dans la même transaction répartie et globale. Soudainement, le serveur B rencontre une défaillance alors que la bean session est en cours (ce qui signifie qu'elle n'a pas encore commencé la validation). Les serveurs C et D attendent davantage de travail ou le début du protocole de validation à deux phases, mais, à ce stade, les verrous transactionnels peuvent encore être maintenus par les gestionnaires de ressources. Les rôles du serveur sont donc les suivants :
  • Serveur A : Servlet/JavaServer Page exécuté
  • Serveur B : Bean session accédée
  • Serveur C : Bean entity accédée
  • Serveur D : Bean entity accédée
Une fois l'expiration déclenchée, du fait que le bean session est en cours au moment de la défaillance, le produit annule la branche de la transaction.

Lorsque des gestionnaires de ressources locaux sont appelés, RRS s'assure qu'il sont appelés pour effectuer le processus d'abandon supposé. Au cours de la reprise, RRS collabore avec les gestionnaires de ressources afin de garantir que la reprise est effectuée convenablement. Lorsqu'une défaillance survient alors qu'un travail est en cours, RRS invite les gestionnaires de ressources impliqués dans la lecture non valide locale à annuler.

Le produit suppose toujours qu'une reprise est à faire. Chaque fois qu'un serveur se présente, il agit différemment en fonction de son mode de fonctionnement.
  • Si le serveur fonctionne en mode redémarrage/reprise, le produit vérifie si une reprise est nécessaire. Si une reprise est nécessaire, le produit tente de la réaliser. Il y parvient ou il s'arrête.
  • Si le serveur fonctionne normalement, la transaction redémarrage/reprise ne doit pas nécessairement être terminée avant que le serveur ne passe à un nouveau travail. Une fois que le serveur a déterminé ce qu'est le travail de redémarrage, il commence à accepter de nouveaux éléments de travail. Le traitement de la transaction redémarrage/reprise se poursuit en parallèle du traitement des nouveaux éléments de travail.

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