Connexions partageables et non partageables

Le serveur d'applications prend en charge les connexions partageables et non partageables. Une connexion est non partageable lorsqu'elle n'est pas partagée avec d'autres composants de l'application. Le composant qui l'utilise bénéficie alors d'un contrôle exclusif sur cette connexion.

L'accès à une ressource marquée "non partageable" signifie qu'il existe une relation bi-univoque entre le descripteur de connexion utilisé par un composant et la connexion physique à laquelle ce descripteur est associé. Par conséquent, chaque appel à la méthode getConnection renvoie un descripteur de connexion uniquement à l'usage du demandeur. Généralement, vous optez pour une connexion non partageable si vous pensez que des ajustements apportés à la connexion peuvent conduire à un comportement inattendu dans une autre application qui partagerait cette connexion (par exemple, la modification imprévue du niveau d'isolement).

Le fait de déclarer une ressource comme "partageable" permet une plus grande extensibilité. La connexion physique (à savoir, la connexion gérée) est partagée par l'intermédiaire de plusieurs descripteurs de connexion, si chaque demande getConnection possède les mêmes propriétés de connexion. Ce partage est préférable à l'extraction d'une nouvelle connexion physique du pool de connexions par appel getConnection(). Cependant, partager une connexion signifie que les utilisateurs ne doivent la soumettre à aucune action qui pourrait modifier son comportement et la rendre inutilisable par l'un de ses bénéficiaires (par exemple, changer le niveau d'isolement). Une application ne peut pas non plus être codée de façon à compter sur un partage systématique des connexions, car seul le contexte d'exécution peut décider de partager ou non une connexion particulière.

Exigences de propriété de connexion

Pour que le partage des connexions utilisées dans la même transaction soit possible, les propriétés de source de données suivantes doivent être identiques :
  • Nom Java™ Naming and Directory Interface (JNDI). Même s'il ne s'agit pas à proprement parler d'une propriété de connexion, cela signifie que vous ne pouvez partager que des connexions issues de la même source de données, dans le même serveur.
  • Authentification de ressource
  • Dans les bases de données relationnelles :
    • Niveau d'isolement (correspond aux règles de tentative d'accès s'appliquant aux beans de persistance gérée par conteneur (CMP)
    • Readonly
    • Catalogue
    • TypeMap
Pour permettre le partage des connexions se trouvant dans la même connexion, les propriétés suivantes doivent être les mêmes pour les fabriques de connexions :
  • Nom JNDI. Même s'il ne s'agit pas à proprement parler d'une propriété de connexion, cela signifie que vous ne pouvez partager que des connexions issues de la même fabrique de connexions dans le même serveur.
  • Authentification de ressource
Par ailleurs, l'objet ConnectionSpec utilisé pour obtenir la connexion doit également être identique.
Remarque : les connexions Java Message Service (JMS) ne peuvent pas être partagées avec des connexions non JMS.

Les connexions JMS pour l'architecture de connecteur Java ( IBM® MQ ) ne peuvent pas être partagées car elles ne sont pas transactionnelles, et la spécification JCA ( Java™ EE Connector Architecture) autorise uniquement le partage des ressources transactionnelles. Si res-sharing-scope est défini comme partageable dans une référence de ressource JMS, le paramètre est ignoré et des connexions non partageables sont utilisées. Toutefois, les sessions JMS d'IBM MQ sont transactionnelles et peuvent être partageables. Les sessions JMS sont partageables par défaut. APAR PK59605 fournit un mécanisme permettant de rendre les sessions JMS non partageables.

Toute connexion JMS gère son propre pool de sessions. La plupart des applications créent une connexion JMS, suivie d'une session JMS. La session JMS est utilisée pour le travail. Une fois ce dernier terminé, la session JMS est fermée. Si l'application doit effectué un travail supplémentaire, elle crée une autre session JMS, l'utilise, puis la ferme. Une fois que l'application a terminé, elle ferme la connexion JMS.

Lorsqu'une application JMS s'exécute dans WebSphere® Application Server et appelle Connection.createSession(), une session est créée et est partageable par défaut. La session JMS reçue par l'application est extraite du pool de sessions associé à la connexion JMS qui a utilisé la méthode. La session étant partageable, elle est automatiquement inscrite dans toute transaction active.

Une fois qu'une application en a fini avec la session, elle appelle Session.close(). La session reste inscrite dans la transaction et conserve son état partageable. La session retourne dans le pool de sessions une fois que la transaction est terminée.

Dans certains cas, lors du traitement des sessions JMS, l'état partageable des sessions peut prolonger la connexion de la session à la transaction. Cette connexion prolongée peut conduire à des inefficacités lors de la gestion du pool de sessions et réduire l'efficacité du traitement des transactions.

Vous pouvez utiliser la propriété personnalisée session.sharing.scope pour rendre des sessions JMS non partageables. Pour une session JMS non partageable, chaque fois qu'une application appelle Session.close() et que le travail de la session JMS est terminé, la session JMS n'est plus associée à une transaction et est renvoyée au pool de sessions comme session libre. Les sessions peuvent donc être nettoyées et supprimées du pool de sessions, même si l'application qui a créé la session est toujours en cours d'exécution.

Pour plus de détails sur la propriété personnalisée session.sharing.scope, reportez-vous aux sources suivantes :

Les connexions JMS pour le fournisseur de messagerie par défaut sont différentes. Avec le fournisseur de messagerie par défaut, les connexions peuvent être partageables. En revanche, les sessions ne sont pas gérées par un pool de connexion et ne sont ni partageables, ni non partageables.

Partage d'une connexion avec un bean CMP

Le serveur d'applications permet de partager une connexion physique entre un bean CMP, un bean BMP et une application JDBC afin de réduire l'allocation de ressources ou d'éviter les scénarios de blocage. Il existe plusieurs moyens de s'assurer que tous ces beans entity et les applications JDBC partagent la même connexion physique.
  • Partage d'une connexion entre beans ou méthodes CMP

    Les méthodes de bean CMP qui utilisent la même tentative d'accès partagent de ce fait la même connexion physique. Une règle de tentative d'accès différente déclenche l'allocation d'une connexion physique différente. Par exemple, un bean CMP possède deux méthodes ; la méthode 1 est associée à la tentative d'accès wsPessimisticUpdate tandis que la méthode 2 est associée à la tentative d'accès wsOptimisticUpdate. La méthode 1 et la méthode 2 ne peuvent partager la même connexion physique dans une transaction. En d'autres termes, une source de données XA est requise pour s'exécuter dans une transaction globale.

    Les accès concurrents des méthodes à la même table peuvent générer des blocages. Par conséquent, le partage d'une connexion est fonction des tentatives d'accès définies dans la méthode CMP.

  • Partage d'une connexion entre beans CMP et beans BMP

    Pensez d'abord à vérifier que les méthodes getConnection des beans BMP et CMP définissent les mêmes propriétés de connexion. Pour faire correspondre le type d'authentification de la ressource de bean CMP, définissez le type d'authentification de la ressource de bean BMP sur container-managed (géré par conteneur), désigné dans le descripteur de déploiement par res-auth = Container.

    Vous pouvez en outre utiliser l'une des options suivantes pour permettre le partage de connexion entre le types de bean :
    • Définissez la même tentative d'accès sur les méthodes des beans CMP et des beans BMP. En utilisant la même tentative d'accès, ces ressources partagent la même connexion physique. L'avantage de cette option est que la base de données dorsale est transparente pour les beans BMP. Cependant, la portabilité des BMP n'est pas assurée du fait qu'ils emploient l'API étendue de WebSphere pour prendre en charge le niveau d'isolement. Pour plus d'informations, reportez-vous à l'exemple de code dans la rubrique Exemple : accès aux données à l'aide des API étendues d' IBM pour partager des connexions entre des beans de persistance gérés par conteneur et gérés par bean.
    • Déterminez le niveau d'isolement employé par la tentative d'accès sur une méthode de bean CMP, puis utilisez ce niveau indiqué sur la référence de ressource pour rechercher une source de données et une connexion. Cette option nécessite plus d'opérations manuelles que la précédente, et le niveau d'isolement peut varier d'une base de données à une autre. Pour plus d'informations, reportez-vous à la table de correspondances des niveaux d'isolement et des tentatives d'accès dans les rubriques Niveaux d'isolement de tentatives d'accès et verrous de mise à jour, d'une part et Niveau d'isolement et référence de ressource, d'autre part.
  • Partage d'une connexion entre CMP et une application JDBC utilisée par un servlet ou un bean session Déterminez le niveau d'isolement employé par la tentative d'accès sur une méthode de bean CMP, puis utilisez le niveau indiqué sur la référence de ressource pour rechercher une source de données et une connexion. Pour plus d'informations, reportez-vous aux rubriques Niveaux d'isolement de tentatives d'accès et verrous de mise à jour, d'une part et Niveau d'isolement et référence de ressource, d'autre part.

Facteurs de détermination du partage

La liste ci-après n'est pas exhaustive. Le produit peut ou non partager les connexions selon les circonstances.
  • Seules sont candidates au partage les connexions acquises avec la même référence de ressource (resource-ref) dans laquelle la propriété res-sharing-scope est spécifiée comme étant partageable. Les propriétés de référence de ressource res-sharing-scope et res-auth ainsi que l'extension IBM isolationLevel permettent de déterminer s'il est possible de partager une connexion. IBM L'extension isolationLevel est stockée dans le fichier de description de déploiement IBM; par exemple : ibm-ejb-jar-ext.xmi.
    Configurations prises en charge : pour les fichiers d'extension et de liaison IBM, l'extension de nom de .xmi.xml fichier ou diffère selon que vous utilisez une application ou un module pré- Java EE 5 ou une application ou un module Java EE 5 ou ultérieur. Un fichier d'extension ou de liaison d' IBM s est nommé ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au type d'extension ou de fichier de liaison, tel que app, application ejb-jar,, ou web. Les conditions suivantes s'appliquent :
    • Pour une application ou un module utilisant une version d' Java EE antérieure à la version 5, l'extension du fichier doit être .xmi.
    • Pour une application ou un module utilisant Java EE 5 ou une version ultérieure, l'extension du fichier doit être .xml. Si des fichiers .xmi sont inclus avec l'application ou le module, le produit ignore les fichiers .xmi.

    Cependant, un module Java EE 5 ou ultérieur peut exister dans une application qui inclut des fichiers pré- Java EE 5 et utilise l'extension de nom .xmi de fichier.

    Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.

  • Seules les connexions demandées avec les mêmes propriétés peuvent être partagées.
  • Les connexions sont partagées entre différentes instances de composant uniquement si ces instances se trouvent dans une transaction (initiée par le conteneur ou l'utilisateur).
  • Le partage de connexions a lieu uniquement dans une limite de partage. Dans la version actuelle du produit, il existe deux types de limites de partage : Transactions et LocalTransactionContainment (LTC, ou "confinement de transaction locale").
  • Les règles de partage de connexions dans une portée LTC sont les suivantes :
    • Pour les connexions partageables, seule la réutilisation de connexion est autorisée dans une même instance de composant. La réutilisation de connexion a lieu lorsque les actions suivantes sont entreprises successivement avec une connexion : obtention, utilisation, validation/annulation, fermeture ; obtention, utilisation, validation/annulation, fermeture. Notez que si vous utilisez la valeur ContainerAtBoundary pour le contrôle de résolution LTC (propriété resolution-control), aucune action de démarrage/validation n'est nécessaire, puisque celle-ci est alors prise en charge par le conteneur.

      La connexion renvoyée en réponse au second appel get est la même que celle obtenue au premier appel get (si les mêmes propriétés sont utilisées). Comme la connexion est réutilisée de façon séquentielle, il n'y a jamais plus d'un descripteur associé à la connexion physique sous-jacente. Il ne s'agit donc pas d'un véritable partage de connexion. Le terme "réutilisation" est plus exact.

      Plus important encore, l'intégration des deux actions get n'est pas effectuée par la limite LocalTransactionContainment ;aucune méthode cleanUp() n'est appelée sur l'objet ManagedConnection. Par conséquent, la deuxième action get hérite de toutes les propriétés de connexion définies lors du premier appel getConnection().

  • Les connexions partageables entre transactions CMT (gérées par le conteneur), BMT (gérées par le bean) ou LTC (confinement de transaction locale) obéissent aux règles de mise en cache suivantes :
    • En règle générale, la définition/modification des propriétés d'une connexion partageable n'est pas autorisée, car le bénéficiaire d'un descripteur pointant sur cette connexion peut ne pas anticiper un changement opéré par un autre descripteur. Cette limitation fait partie de la norme Java Platform, Enterprise Edition ( Java EE ).
    • Les utilisateurs d'adaptateurs de ressources peuvent définir les propriétés de la connexion sur l'appel getConnection() de fabrique de connexions en les passant dans un objet ConnectionSpec.

      Cependant, il n'est pas garanti que les propriétés définies sur la connexion au cours d'une transaction seront les mêmes dans la transaction suivante. Comme il n'est pas permis de partager des connexions en dehors d'une portée de partage, lorsqu'une transaction prend fin, les descripteurs de connexions attachés à la connexion physique sont détachés de celle-ci. Cette connexion physique est restituée au pool de connexions libres. Les connexions sont "nettoyées" avant d'être replacées dans le pool de connexions libres. Lors de l'utilisation suivante du descripteur, celui-ci est automatiquement associé à une connexion adéquate, laquelle est déterminée d'après les informations de sécurité (authentification), les propriétés de connexion et (pour l'API JDBC) le niveau d'isolement spécifié dans la référence de ressource étendue passée dans la première demande qui a renvoyé le descripteur actuel. Toutes les propriétés qui ont été définies sur la connexion après qu'elle a été obtenue sont perdues.

    • Pour les utilisateurs JDBC, le serveur d'applications fournit une extension qui permet de passer les propriétés de connexion dans un objet ConnectionSpec.

      Soyez prudent lorsque vous partagez une connexion et que vous définissez ses propriétés dans une portée de transaction locale. Assurez-vous que les autres composants avec lesquels la connexion est partagée s'attendent au comportement résultant de vos modifications.

  • Dans le cas de l'API JDBC, vous ne pouvez définir le niveau d'isolement sur une connexion partageable avec un adaptateur de ressources relationnelles dans une transaction globale. Le produit fournit une extension de la référence de ressource pour vous permettre de spécifier le niveau d'isolement. Si votre application nécessite l'utilisation de plusieurs niveaux d'isolement, créez autant de références de ressources qu'il y a de niveaux et mappez-les vers la même source de données ou fabrique de connexions.

Partage maximal de connexions

Pour optimiser les opportunités de partage de connexion pour une application, assurez-vous que chaque composant dispose de l'attribut de programme de résolution LTC ayant la valeur ContainerAtBoundary. Ce paramètre indique que le conteneur de composant, et non le code d'application, résout toutes les transactions locales du gestionnaire de ressources (RMLT) dans la portée LTC. Le conteneur démarre une RMLT lorsqu'une connexion est d'abord utilisée dans la portée LTC et la termine automatiquement à la fin de la portée LTC.

Pour obtenir les instructions requises pour définir le contrôle de résolution des transactions et d'autres attributs, voir la rubrique Configuration des attributs de déploiement transactionnel.

Violations du partage de connexions

Il existe une nouvelle exception, l'exception de violation de partage, que l'adaptateur de ressources peut générer chaque fois qu'une opération viole les conditions de partage. Les violations possibles sont entre autres la modification des attributs de connexion, des paramètres de sécurité ou des niveaux d'isolement. Lorsqu'une opération modifiable de ce type est effectuée par rapport à une connexion gérée, l'exception de violation de partage peut être générée si les deux conditions suivantes sont remplies :
  • Le nombre de descripteurs de connexion associés à la connexion gérée est supérieur à un.
  • La connexion gérée est associée à une transaction, soit locale, soit XA.

Le composant et l'environnement d'exécution J2C peuvent avoir besoin de détecter cette exception de violation de partage, selon le moment et la façon dont la connexion gérée devient non partageable. Si la connexion gérée devient non partageable en raison d'une opération effectuée par le biais du descripteur de connexions (par exemple, si vous avez modifié le niveau d'isolement), alors le composant a besoin de traiter l'exception. Si elle devient non partageable sans que cela ne soit reconnu par le serveur d'applications (du fait d'une interaction entre le composant et le descripteur de connexion), l'adaptateur de ressources peut refuser la création d'un descripteur de connexion en générant une exception de violation de partage.