Remarques sur les connexions lors de la migration des servlets, des fichiers JSP (JavaServer Pages) ou des beans session enterprise
Si vous avez l'intention de mettre à niveau vers WebSphere Application Server Version 7.0 ou ultérieures et de migrer les applications de la version 1.2 de la spécification J2EE (Java™ 2 Platform, Enterprise Edition) vers une version ultérieure, telle que 1.4 ou J2EE (Java Platform, Enterprise Edition (Java EE), il vous faut savoir que le produit attribue des connexions partageables et non partageables de manière différente pour les composants des applications après la version 1.2. Pour certaines applications, cette différence peut provoquer une dégradation des performances.
Modifications de comportement
Du fait que WebSphere Application Server assure la compatibilité amont avec les modules d'application codés conformément à la spécification J2EE 1.2, vous pouvez continuer à utiliser des sources de données de type version 4 lorsque vous migrez vers WebSphere Application Server Version 7.0 ou ultérieures Aussi longtemps que vous configurez des sources de données Version 4 uniquement pour les modules J2EE 1.2, le comportement de vos composants d'applications d'accès aux données ne change pas.
Toutefois, si vous adoptez une version ultérieure de la spécification J2EE en même temps que votre migration versWebSphere Application Server Version 7.0 ou ultérieures, le comportement de vos composants d'accès aux données peut changer. De façon plus précise, ce risque s'applique aux applications qui contiennent des servlets, des fichiers JSP ou des beans session enterprise qui s'exécutent dans des transactions locales sur des connexions partageables. Un changement de comportement dans les composants d'accès aux données peut affecter l'utilisation des connexions dans ces applications.
Ce changement affecte toutes les applications contenant les méthodes suivantes :
- RequestDispatcher.include()
- RequestDispatcher.forward()
- Inclusions JSP (<jsp:include>)
Les signes d'erreurs sont les suivants :
- Fin anormale de session
- Délai d'expiration de la session
- Absence de connexion
Le commutateur attribue des connexions partageables et non partageables
Pour les modules J2EE 1.2 utilisant des sources de données Version 4, WebSphere Application Server émet des connexions non partageables vers les fichiers JSP, les servlets et les beans session enterprise. Des connexions partageables sont émises pour toutes les autres applications. Cependant, pour les modules J2EE 1.3 et ultérieurs, le serveur d'applications émet des connexions partageables vers toutes les ressources nommées de façon logique (des ressources liées à des références individuelles), à moins que vous ne spécifiiez les connexions comme étant non partageables dans les références de ressource individuelles. Dans ce contexte, l'utilisation de connexions partageables produit les effets suivants :
- Aucune connexion reçue et utilisée hors de la portée d'une transaction utilisateur n'est renvoyée au pool de connexions disponibles avant le retour de la méthode d'encapsulation, et ce, même quand le descripteur de connexion spécifie un appel close().
- Aucune connexion reçue et utilisée hors de la portée d'une transaction utilisateur n'est partagée avec d'autres instances de composants (servlets, fichiers JSP ou beans enterprise). Par exemple, le bean session 1 établit une connexion, puis appelle le bean session 2 qui en établit une autre. Même si les propriétés sont toutes identiques, chaque bean session reçoit sa propre connexion.
Si vous n'avez pas anticipé ce changement dans le comportement des connexions, la façon dont vous avez structuré le code d'application peut conduire à une utilisation excessive des connexions, en particulier dans les inclusions JSP, les beans session s'exécutant à l'intérieur de transactions sur des connexions partageables, les routines RequestDispatcher.include() et RequestDispatcher.forward(), ou les appels d'autres composants à partir de ces méthodes. Ainsi, vous pourrez subir des blocages de session, des expirations de délais ou des problèmes de connexion.
Exemple de scénario
Le servlet A obtient une connexion, effectue le traitement, valide la connexion et appelle close() sur la connexion. Puis, le servlet A appelle RequestDispatcher.include() pour inclure le servlet B, qui effectue les mêmes opérations que le servlet A. Du fait que la connexion du servlet A ne retourne pas dans le pool des connexions disponibles avant son renvoi par la méthode en cours, deux connexions sont à présent établies. Ainsi, un nombre de connexions plus important que prévu peut être en cours d'utilisation dans votre application. Si ces connexions ne sont pas prises en compte dans le paramètre Nombre maximal de connexions du pool de connexions, ce pool risque de se trouver à court de connexions, provoquant ainsi des exceptions ConnectionWaitTimeOut. Si le délai maximal d'attente de connexion est inactif ou trop important, ces unités d'exécution semblent être figées car elles attendent des connexions qui ne sont jamais libérées dans le pool. Les unités d'exécution en attente de nouvelles connexions ne renvoient pas celles qu'elles utilisent si les nouvelles connexions ne sont pas disponibles.
Résolution
Pour résoudre ces incidents, procédez comme suit :
- Utilisez des connexions non-partagées.
Si vous utilisez une connexion non partagée alors que vous ne traitez pas de transaction utilisateur, la connexion retourne dans le pool des connexions disponibles quand vous émettez un appel close() (à condition que vous validiez ou annuliez la connexion).
- Augmentez le nombre maximal de connexions.
Pour calculer le nombre de connexions requises, multipliez le nombre d'unités d'exécution configurées par le niveau le plus profond d'imbrication des appels de composant (pour les appels qui utilisent des connexions). Voir la section Exemple de scénario pour la description de l'imbrication des appels.