Modèle d'utilisation des sessions ActivitySession avec des sessions HTTP

La présente rubrique indique comment une application Web exécutée dans le conteneur Web de WebSphere peut participer à un contexte ActivitySession.

Si l'application Web est conçue afin que plusieurs appels de servlets surviennent dans le cadre de la même application logique, les servlets peuvent utiliser la session HTTP pour conserver leur état d'un appel à un autre. Le contexte ActivitySession est un état qui peut être suspendu dans la session Http et repris lors d'un appel ultérieur d'un servlet accédant à cette dernière.

Une session ActivitySession est associée automatiquement à une session Http. Cela permet d'étendre l'accès à la session ActivitySession pendant plusieurs appels HTTP, pendant l'inclusion ou l'acheminement des servlets et de prendre en charge les périodes d'activation d'EJB (Enterprise JavaBeans) qui peuvent être déterminées par le cycle de vie du client HTTP Web. Un contexte ActivitySession stocké dans une session Http peut aussi servir à réassocier le travail à effectuer pour la session ActivitySession à un client HTTP Web spécifique.

Le conteneur Web gère les sessions ActivitySession en fonction des attributs du descripteur de déploiement associés aux servlets dans le module d'application Web. Les deux modèles d'utilisation sont les suivants :
  • Le conteneur Web démarre et arrête les sessions ActivitySession.
    L'application Web appelle un servlet qui a été configuré pour le contrôle par conteneur des sessions ActivitySessions.
    • S'il existe une HttpSession, une ActivitySession lui est associée.
    • S'il n'existe aucune HttpSession, le servlet peut lancer une HttpSession, ce qui lance automatiquement une ActivitySession et l'associe à la HttpSession.

    Un servlet ne peut pas lancer de nouvelle HttpSession avant l'arrêt d'une HttpSession existante. Dans une HttpSession, l'application Web peut appeler d'autres servlets qui peuvent utiliser le contexte ActivitySession associé. Lorsque l'application Web appelle un servlet qui arrête la HttpSession, l'ActivitySession est arrêtée automatiquement. Cela est illustré par le diagramme suivant :

    Figure 1. Contrôle par conteneur Web des ActivitySessions. Cette figure est décrite dans le texte.Contrôle par conteneur Web des ActivitySessions, décrit dans le texte accompagnant cette figure
  • L'application Web démarre et arrête les ActivitySessions.
    L'application Web appelle un servlet qui a été configuré pour le contrôle par application des ActivitySessions.
    • S'il existe une HttpSession et qu'une ActivitySession lui est associée, le servlet peut utiliser ou arrêter ce contexte ActivitySession.
    • S'il n'existe aucune HttpSession, le servlet peut lancer une HttpSession, mais cela ne lance pas automatiquement d'ActivitySession.
    • S'il existe une HttpSession mais qu'aucune ActivitySession ne lui est associée, le servlet peut lancer une nouvelle ActivitySession. L'ActivitySession est alors associée automatiquement à la HttpSession. L'ActivitySession dure jusqu'à l'arrêt spécifique de l'ActivitySession ou l'arrêt de la HttpSession.

    Le servlet ne peut pas lancer de nouvelle ActivitySession avant l'arrêt d'une ActivitySession existante. Le servlet ne peut pas lancer de nouvelle HttpSession avant l'arrêt d'une HttpSession existante.

    Dans une HttpSession, l'application Web peut appeler d'autres servlets qui peuvent utiliser ou arrêter un contexte ActivitySession existant ou, s'il n'existe aucune ActivitySession, lancer une nouvelle ActivitySession. Lorsque l'application Web appelle un servlet qui arrête la HttpSession, l'ActivitySession est arrêtée automatiquement. Cela est illustré par le diagramme suivant :

    Figure 2. Contrôle par application Web des ActivitySessions,. Cette figure est décrite dans le texte.Contrôle par application Web des ActivitySessions, décrit dans le texte accompagnant cette figure

Une application Web peut appeler des servlets configurés pour un modèle d'utilisation.

Les points suivants s'appliquent aux deux modèles d'utilisation :

  • Pour mettre fin à une HttpSession (et une ActivitySession associée), l'application Web doit invalider cette session. L'ActivitySession est alors soumise à des points de contrôle
  • Tout bean enterprise aval activé dans le contexte de la session ActivitySession peut être mémorisé plutôt que désactivé entre les appels de servlet car le client devient réellement le client HTTP Web.
  • Les applications Web peuvent comporter de nombreux servlets et chacun d'eux peut être configuré avec la même valeur définie pour ActivitySessionControl. ActivitySessionControl détermine si le servlet ou son conteneur lance des ActivitySessions.
  • Un contexte ActivitySession encapsulant un contexte de transaction actif ne peut pas être associé à une session Http car une transaction peut comporter des verrous de base de données et doit être conçue pour une courte durée de vie. Le déplacement d'une transaction active vers une session HttpSession par une application a pour effet d'annuler la transaction et de suspendre la session ActivitySession dans la session HTTP. Généralement, vous devez concevoir les applications en vue de l'utilisation des sessions ActivitySession ou d'autres constructions, comme les entités de longue durée de vie, et des transactions ACID, comme les entités de courte durée de vie au sein de celles-ci.
  • A tout moment, une seule session ActivitySession peut être associée, pour sa durée, à une session Http. Une ActivitySession qui est associée à une HttpSession le reste pour la durée de cette ActivitySession et ne peut pas être remplacée par une autre session avant la fin de la première ActivitySession. La session ActivitySession est accessible à plusieurs servlets s'ils partagent l'accès à la session Http.
  • Les sessions ActivitySessions ne sont pas persistantes. Si une session Http persistante dure plus longtemps que le serveur qui l'héberge, toute session ActivitySession placée dans la mémoire cache est interrompue lorsque le serveur d'hébergement s'arrête.
  • Si la session HttpSession arrive à expiration avant que la session ActivitySession associée soit terminée, la session est redéfinie1. Les ressources ActivitySession sont rétablies au niveau du dernier point de cohérence dans les cas suivants :
    • Si l'application Web a appelé un servlet qui a été configuré pour le contrôle par conteneur des sessions ActivitySession, les ressources ActivitySession sont complètement rétablies.
    • Si l'application Web a appelé un servlet qui a été configuré pour le contrôle par application des sessions ActivitySession, les ressources ActivitySession sont rétablies au niveau du dernier point de contrôle effectué par le servlet ou complètement, si aucun point de contrôle n'a été effectué.
  • Si le délai d'attente de la session ActivitySession est dépassé, celle-ci est réinitialisée au niveau du dernier point de cohérence (voir point précédent), puis la session HttpSession prend fin.
1 Lorsque la session ActivitySession est redéfinie, toutes les ressources utilisées dans la session ActivitySession en cours sont rétablies au niveau du dernier point de cohérence, mais il est possible de continuer d'utiliser la session ActivitySession. Une fois la session redéfinie, l'unité d'exécution est associée à la session ActivitySession à laquelle elle était associée avant que cette dernière ne soit redéfinie. Les ressources ActivitySession restent associées à la session ActivitySession, mais elles ne peuvent plus y être utilisées

Icône indiquant le type de rubrique Rubrique de référence



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