Délimiteur de transaction locale
IBM® WebSphere Application Server prend en charge le délimiteur de transaction locale (LTC, local transaction containment), que vous pouvez configurer par le biais des descripteurs de déploiement étendus de transactions locales. Le support LTC procure certains avantages aux programmeurs d'application. Utilisez les scénarios fournis et les éléments à prendre en compte pour déterminer la meilleure façon de configurer le support de transactions pour les transactions locales.
Les sections qui suivent présentent les avantages que procure la prise en charge de LTC et explique comment définir les descripteurs de déploiement étendus de transactions locales dans chaque situation.
- Vous pouvez développer un bean enterprise ou un servlet ayant accès à une ou plusieurs bases de données indépendantes et ne nécessitant aucune coordination.
- Si un bean enterprise n'a pas besoin d'utiliser de transactions globales, il s'avère souvent plus efficace de le déployer avec le descripteur de déploiement du
type de transaction de conteneur dont la valeur est NotSupported et
non Required.
Grâce au support étendu des transactions locales du serveur d'applications, les applications peuvent exécuter la même logique métier dans un contexte de transaction non spécifié que dans un contexte de transaction globale. Un bean enterprise, par exemple, s'exécute dans un contexte de transaction non spécifié s'il est déployé avec un type type de transaction de conteneur NotSupported ou Never.
Le support étendu des transactions locales fournit une limite des transactions locales implicite gérée par le conteneur à l'intérieur de laquelle le conteneur valide les mises à jour d'application et nettoie leurs connexions. Vous pouvez concevoir des applications avec plus d'indépendance par rapport aux questions de déploiement. Cela simplifie l'utilisation d'un type de transaction de conteneur de valeur Supports, par exemple lorsque la logique métier peut être appelée avec ou sans contexte de transaction globale.
Une application peut suivre un modèle d'utilisation des connexions de type "get-use-close" (obtention/utilisation/fermeture), qu'elle s'exécute ou non dans le contexte d'une transaction. L'application peut dépendre du comportement identique de l'action close dans toutes les situations, sans entraîner d'annulation de la connexion en l'absence de transaction globale.
Il existe de nombreux scénarios dans lesquels la coordination ACID de plusieurs gestionnaires de ressources n'est pas nécessaire. Dans de tels cas, l'exécution de la logique métier dans une règle Transaction avec pour valeur NotSupported est plus efficace que dans une règle avec pour valeur Required. Vous devez alors attribuer la valeur ContainerAtBoundary au descripteur de déploiement dans la section Local Transactions de l'attribut Resolver. Avec cette valeur, les interactions des applications avec ces fournisseurs de ressources, tels que les bases de données, sont gérées dans des transactions RMLT implicites que le conteneur démarre et arrête. Le conteneur valide les transactions RMLT à la limite du confinement indiquée par l'attribut Boundary dans la section Local Transactions, par exemple, à la fin d'une méthode. Si l'application renvoie le contrôle au conteneur à travers une exception, le conteneur annule toutes les transactions RMLT qu'il a démarrées.
Cette utilisation s'applique à la fois aux servlets et aux beans enterprise.
- Vous pouvez utiliser des transactions locales dans un environnement géré qui garantit le nettoyage.
- Les applications qui souhaitent contrôler les transactions RMLT, en
les démarrant et en les terminant de façon explicite, peuvent utiliser la
valeur par défaut Application du descripteur de déploiement étendu
Resolver dans la section Local Transactions. Dans ce cas, le conteneur
assure le nettoyage de la connexion à la limite du contexte de la
transaction locale.
Les spécifications de la platforme Java™ pour des applications d'entreprise qui décrivent l'utilisation des transactions locales dans les applications se basent sur les valeurs par défaut Application du descripteur de déploiement étendu Resolver et Rollback pour le descripteur de déploiement étendu de l'action Unresolved dans la section Local Transactions. Lorsque le descripteur de déploiement étendu de l'action Unresolved dans la section Local Transactions prend la valeur Commit, le conteneur valide toutes les transactions RMLT démarrées par l'application, mais par encore terminées au moment où le confinement de transaction locale prend fin (par exemple, à la fin de la méthode). Cette utilisation s'applique à la fois aux servlets et aux beans enterprise.
Vous pouvez étendre la durée d'une transaction locale au-delà de la durée d'une méthode de composant EJB.
Les spécifications Enterprise JavaBeans (EJB) limitent l'utilisation des RMLT aux méthodes EJB uniques. Cette restriction est liée au fait que les spécifications ne disposent pas de dispositif de sectorisation, au-delà d'une limite de méthode imposée par le conteneur, en fonction duquel une RMLT peut être étendue. Vous pouvez utiliser le descripteur de déploiement étendue Limite à la section Transactions locales pour profiter des avantages suivants :
- Etendre de façon significative les scénarios d'utilisation de transactions RMLT.
- Rendre possibles les interactions conversationnelles avec les gestionnaires de ressources à phase unique à travers le support du service ActivitySession.
Vous pouvez recourir à un service ActivitySession pour offrir un contexte distribué avec un limite plus longue qu'une méthode. Vous pouvez étendre l'utilisation des RMLT jusqu'à la limite ActivitySession plus longue qu'un client peut contrôler. La limite ActivitySession réduit le besoin d'utiliser des transactions réparties dans lesquelles les opérations ACID sur plusieurs ressources ne sont pas requises. Cet avantage s'obtient via le paramètre de déploiement étendu Limite ActivitySession à la section Transactions locales. Ces transactions RMLT étendues peuvent rester sous le contrôle de l'application ou être gérées par le conteneur en fonction de la valeur du descripteur de déploiement Resolver dans la section Local Transactions.
- Vous pouvez coordonner plusieurs gestionnaires de ressources à phase unique.
- Pour les gestionnaires de ressources qui ne prennent pas en charge la coordination des transactions XA, un client peut utiliser les contextes de transactions locales liés à ActivitySession. Ces contextes confèrent à un client la même capacité à contrôler le sens d'aboutissement des mises à jour des ressources par les gestionnaires de ressources que celle dont il dispose pour les gestionnaires de ressources de transactions. Un client peut démarrer un service ActivitySession et appeler ses beans entity dans ce contexte. Ces beans peuvent exécuter leurs transactions RMLT dans la portée de ce service ActivitySession et rendre le contrôle sans terminer les RMLT. Le client peut terminer le service ActivitySession ultérieurement dans le sens de la validation ou de l'annulation et pousser ainsi le conteneur à diriger les RMLT liées à ActivitySession dans le même sens coordonné.
- Vous pouvez utiliser des LTC partageables afin de réduire le nombre de connexions requises.
- Les composants d'application peuvent se partager des LTC. Si les composants se connectent au même gestionnaire de ressources, ils peuvent se partager cette connexion s'ils s'exécutent sous la même transaction globale ou LTC partageable. Pour configurer deux composants pour qu'ils s'exécutent sous le même LTC partageable, définissez l'attribut Shareable de la section Local Transactions dans le descripteur de déploiement de chaque composant. Vérifiez que la référence aux ressources dans le descripteur de déploiement de chaque composant utilise la valeur par défaut de l'attribut Shareable pour l'élément res-sharing-scope, si cet élément est indiqué. Un LTC partageable peut réduire le nombre de RMLT utilisé par une application. Par exemple, une application qui utilise fréquemment le module web, y compris les appels, peut partager des connexions au gestionnaire de ressources entre ces modules Web, exploitant soit des LTC partageables, soit une transaction globale, et réduisant le conflit d'accès aux ressources.
Exemples de configurations de la prise en charge des transactions locales
La liste qui suit présente des scénarios qui utilisent des transactions locales et des aspects à prendre en compte pour déterminer la meilleure façon de configurer le support de transactions pour les transactions locales pour une application.
- Vous souhaitez démarrer et terminer les transactions globales de façon
explicite dans l'application (uniquement pour les beans session de type BMT et
les servlets).
Pour un bean session, affectez la valeur Bean au type Transaction (pour utiliser des transactions gérées par bean) dans le descripteur de déploiement du composant. Il est inutile de procéder ainsi pour les servlets.
Vous souhaitez accéder à une seule ressource XA ou non XA dans une méthode.
Vous devez alors attribuer la valeur ContainerAtBoundary à l'attribut Resolver dans la section Local Transactions du descripteur de déploiement du composant. Dans la section Container Transactions, attribuez la valeur Supports au type de transaction de conteneur.
- Vous souhaitez accéder à plusieurs ressources XA de façon atomique par le biais d'une ou plusieurs méthodes de bean.
Vous devez alors attribuer la valeur Required, RequiresNew ou Mandatory au type de transaction de conteneur dans la section Container Transactions du descripteur de déploiement du composant.
Vous souhaitez accéder à plusieurs ressources non XA dans une méthode sans avoir à gérer vos propres transactions locales.
Vous devez alors attribuer la valeur ContainerAtBoundary à l'attribut Resolver dans la section Local Transactions du descripteur de déploiement du composant. Dans la section Container Transactions, attribuez la valeur NotSupported au type de transaction de conteneur.
- Vous souhaitez accéder à plusieurs ressources non XA dans une méthode et les gérer de façon indépendante.
Vous devez alors attribuer la valeur Application à l'attribut Resolver, et la valeur Rollback à l'attribut de l'action Unresolved dans la section Local Transactions du descripteur de déploiement du composant. Dans la section Container Transactions, attribuez la valeur NotSupported au type de transaction de conteneur.
Vous souhaitez accéder à une ou plusieurs ressources non XA à travers plusieurs appels de méthode EJB sans avoir à gérer vos propres transactions locales.
Vous devez alors attribuer la valeur ContainerAtBoundary à l'attribut Resolver et la valeur ActivitySession à l'attribut Boundary dans la section Local Transactions du descripteur de déploiement du composant. Dans la section Bean Cache, attribuez la valeur ActivitySession à l'attribut Activate. Dans la section Container Transactions, attribuez la valeur NotSupported au type de transaction de conteneur et la valeur Required, RequiresNew ou Mandatory à l'attribut kind ActivitySession.
Vous souhaitez accéder à plusieurs ressources non XA via plusieurs appels de méthode EJB et les gérer de façon indépendante.
Vous devez alors attribuer la valeur Application à l'attribut Resolver et la valeur ActivitySession à l'attribut Boundary dans la section Local Transactions du descripteur de déploiement du composant. Dans la section Bean Cache, attribuez la valeur ActivitySession à l'attribut Activate. Dans la section Container Transactions, attribuez la valeur NotSupported au type de transaction de conteneur et la valeur Required, RequiresNew ou Mandatory à l'attribut kind ActivitySession.
Il est préférable d'utiliser une ressource non XA avec des ressources RRS à deux phases multiples.
Les ressources non XA des transactions avec ressources RRS sont prises en charge chaque fois qu'une transaction globale est active. Une transaction globale est active lorsque le descripteur de déploiement du type de transaction de conteneur a pour valeur Supports, Required, RequiresNew ou Mandatory. Les transactions globales sont également actives pour les déploiements gérés par composants. Le conteneur gère la réalisation de la transaction locale de la ressource non XA en même temps que celle des ressources RRS.