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 devez opter pour une connexion non partageable si vous êtes susceptible de la soumettre à une action qui pourrait 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é. Au lieu d'extraire une nouvelle connexion physique du pool de connexions pour chaque appel getConnection(), la connexion physique (à savoir la connexion gérée) est partagée via des descripteurs de connexion dès lors que chaque demande getConnection a les mêmes propriétés de connexion. 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 il revient au contexte d'exécution (runtime) de décider de partager ou non une connexion particulière.
Exigences de propriété de connexion
- Nom JNDI (Java™ Naming and Directory Interface). 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 CMP)
- Readonly
- Catalog
- TypeMap
Pour plus d'informations sur le partage d'une connexion avec un bean CMP, voir la rubrique Partage d'une connexion avec un bean CMP.
- 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
Les connexions du fournisseur JMS de IBM MQ ne sont pas partageables, car elles ne sont pas transactionnelles, et la spécification de l'architecture JCA (Java EE Connector Architecture) n'autorise le partage des ressources que si celle-ci sont transactionnelles. Si res-sharing-scope est défini comme partageable dans une référence de ressource JMS, le paramètre sera ignoré et des connexions non partageables seront utilisées. Cependant, les sessions JMS de MQ sont transactionnelles et peuvent être partageables. Les sessions JMS sont partageables par défaut, et le correctif APAR PK59605 donne la possibilité de définir des sessions non partageables.
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
- 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 de la rubrique Exemple d'accès aux données en utilisant les API étendues d'IBM® pour partager des connexions entre beans CMP et beans BMP.
- 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 ressources de res-sharing-scope et res-auth ainsi que l'extension
IBM isolationLevel
permettent de déterminer s'il est possible de partager une connexion. La propriété isolationLevel
de l'extension IBM
est stockée dans le fichier d'extension de descripteur de déploiement
IBM ; ibm-ejb-jar-ext.xmi, par exemple.
Configurations prises en charge: Pour les fichiers de liaison et d'extension IBM, l'extension de nom de fichier .xmi ou .xml est différente selon que vous utilisiez un module ou une application antérieure à Java EE 5 ou un module ou une application ultérieure à Java EE 5. Un fichier de liaison ou d'extension IBM porte le nom ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au fichier d'extension ou de liaison, tel app, application, ejb-jar ou web. Les conditions suivantes s'appliquent :
Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.
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.
sptcfg - 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. Les limites de partage Current incluent les limites Transactions et LocalTransactionContainment (LTC).
- 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 de getConnection().
- 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.
- 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 EE (Java Platform, Enterprise Edition).
- 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
- 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.