Tâches de définition de profil d'application

Les tâches sont appelées unités de travail. Elles constituent le mécanisme selon lequel l'environnement d'exécution détermine quelles stratégies de tentative d'accès appliquer lorsque des données de bean entity sont chargées à partir du système dorsal.

Un profil d'application permet aux développeurs de configurer un bean entity avec plusieurs stratégies de tentative d'accès. S'il y a n instances de profils dans une application donnée, chaque bean peut être configuré avec n stratégies de tentative d'accès.

Une tâche est associée à une transaction ou une ActivitySession au lancement de l'unité de travail. La tâche, qui ne peut pas être modifiée durant toute la durée de l'unité de travail, est toujours disponible dans la portée de cette unité de travail pour appliquer la stratégie de tentative d'accès configurée pour cette unité de travail particulière.

Si une application d'entreprise est configurée pour utiliser un profil d'application dans chaque partie de l'application, alors le profil d'application est actif et les configurations de tentative d'accès de niveau méthode sont ignorées lorsque les unités de travail sont associées aux tâches connues par l'application.

Lorsqu'un bean entity est chargé dans une unité de travail non associée à une tâche, ou associée à une tâche non associée à un profil d'application, la configuration par défaut de tentative d'accès de niveau bean ou de niveau méthode est appliquée. Si une unité de travail est associée à une tâche configurée avec un profil d'application, la configuration de tentative d'accès de niveau bean du profil d'application approprié est appliquée.

Remarque : La configuration du profil d'application correspond aux données de configuration de la portée de l'application. Si un module EJB (Enterprise Javabeans) contient une configuration de profil d'application, tous les autres modules EJB sont régulés de manière implicite par le service de profilage d'application, même s'ils ne contiennent pas de données de configuration de profil d'application.

Prenons le cas d'une application possédant deux modules EJB : EJBModule1 et EJBModule2.

EJBModule1 possède un profil d'application intitulé AppProfile1. Ce profil AppProfile1 est enregistré par une tâche intitulée task1. Cette tâche devient une tâche connue de l'application, effectuée lorsqu'elle est associée à une unité de travail de cette application. Dès lors qu'il existe une tâche connue de l'application, les configurations de tentative d'accès au niveau méthode sont ignorées et seules celles au niveau du bean sont appliquées.

Le module EJBModule2 ne contient pas de données de configuration de profil d'application. Les beans entity ne sont pas tous configurés explicitement avec une tentative d'accès au niveau des beans, mais certaines méthodes possèdent des configurations de tentative d'accès au niveau des méthodes. Si un bean entity du module EJBModule2 est chargé dans une unité de travail associée à la tâche task1, la configuration de tentative d'accès au niveau du bean est appliquée et celle au niveau méthode est ignorée. La tentative d'accès au niveau du bean n'étant pas définie de manière explicite, la tentative d'accès par défaut au niveau du bean (wsPessimisticUpdate-WeakestLockAtLoad) est appliquée.

La tâche active dépend du mécanisme de l'unité de travail en cours. Si l'unité de travail en cours est une transaction globale, alors la tâche correspond au nom associé à cette transaction. Si la transaction globale n'est pas nommée lors de son lancement, alors aucune tâche active ne se trouve dans la portée de cette transaction.

Si l'unité de travail en cours est une transaction locale associée à une ActivitySession, la tâche correspond au nom associé à cette ActivitySession. Si ActivitySession n'est pas nommée lors de son lancement, alors aucune tâche active n'est liée à cette ActivitySession pour aucune transaction locale. Si l'unité de travail en cours est une transaction locale non associée à une ActivitySession, la tâche correspond au nom associé à cette transaction locale. Si la transaction locale n'est pas associée à une tâche lors de son lancement, alors il n'y a aucune tâche active pour la durée de cette transaction locale. En d'autres termes, la tâche active est la tâche associée à l'unité de travail de l'unité d'exécution qui coordonne les ressources de la base de données. Si l'unité de travail de contrôle n'est pas associée à une tâche lors de son lancement, alors il n'y a aucune tâche active dans la portée de cette unité de travail.

Par exemple, considérez une application de secteur scolaire qui effectue des appels via un bean session pour interagir avec les données des étudiants. Une méthode de bean session permet aux administrateurs de modifier les données des étudiants. Une autre méthode prend en charge les requêtes des étudiants qui souhaitent afficher leur données. En l'absence de profil d'application, les deux tâches fonctionnent de façon anonyme et l'environnement d'exécution ne peut pas faire la différence entre des travaux des différentes tâches. Pour optimiser l'application, un développeur peut configurer l'une des méthodes du bean session avec la tâche "updateRecords" et l'autre méthode du bean session avec la tâche "readRecords". Lorsqu'elle est enregistrée avec un profil d'application dans lequel est configuré le bean d'étudiant avec la tentative d'accès de verrouillage appropriée, la tâche "updateRecords" ne bloquera pas inutilement les transactions qui ne nécessitent qu'une lecture des données. Pour plus d'informations sur les relations entre les tâches et les unités de travail, voir Remarques sur les tâches et les unités de travail.

Les tâches peuvent être configurées de façon à être gérées par le conteneur ou à être établies par programmation par l'application. Les tâches gérées par le conteneur peuvent être configurées sur les servlets, les fichiers JSP (JavaServer Pages), les clients d'application et les méthodes EJB (Enterprise JavaBeans). Les tâches gérées par le conteneur sont uniquement associées aux unités de travail lancées par le conteneur après la définition du nom de la tâche. Les tâches gérées par l'application peuvent être configurées sur tous les composants J2EE. Dans le cas de beans enterprise, il doit s'agir de transactions gérées par bean.

Pratiques recommandées Pratiques recommandées: Si vous sélectionnez l'attribut de mode de compatibilité 5.x sur la page du service de profil d'application de la console, les tâches configurées sur les applications J2EE 1.3 ne sont pas systématiquement associées aux unités de travail et peuvent être appliquées ou remplacées de façon arbitraire. Ce mode d'opération n'est pas recommandé et peut provoquer des blocages imprévus pendant l'accès à la base de données. Les tâches ne sont pas communiquées à la demande entre les applications exécutées sous le mode de compatibilité Application Profiling 5.x et les applications qui ne le sont pas.

Pour qu'un client Version 6.x puisse interagir avec des applications exécutées sous le mode de compatibilité Application Profiling 5.x, vous devez attribuer à la propriété système appprofileCompatibility la valeur true dans le processus client. Ceci peut être fait en spécifiant l'option -CCDappprofileCompatibility=true lors de l'appel de la commande launchClient.

best-practices

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