J'ai récemment hérité du code, dans lequel j'ai trouvé une connexion JDBC étant initialisée dans un filtre et ajouté la HTTPSession pour chaque utilisateur. Cette connexion est ensuite réutilisée dans toutes les différentes parties de l'application Web pour l'utilisateur. Cela m'a immédiatement démarré comme une odeur de code. J'aimerais retourner au développeur qui l'a écrit et explique pourquoi il ne devrait pas faire ça ... mais peut-être que je ne suis pas si sûr de moi ...
En plus de prendre des espaces inutiles en mémoire et de limiter potentiellement les connexions disponibles à la base de données, y a-t-il d'autres raisons pour lesquelles vous ne stockez pas une connexion JDBC lors d'une session?
4 Réponses :
Vous avez mentionné l'évident, un utilisateur à une connexion de base de données n'est pas évolutif. Vos utilisateurs doivent être complètement découplés de l'accès au modèle de données. Voici quelques problèmes que vous rencontrerez.
Le problème de sécurité du fil est un bon point et les connexions faciles. Je suppose que je cherchais juste à voir à quel point une pratique est grave.
Une idée entière de maintenir les connexions JDBC comme haut dans la pile que dans httpsession ou même accéder aux connexions JDBC sur la couche de servlet n'atteint pas beaucoup de sens. Il est de plus en plus logique de mettre en place les connexions sur le serveur d'applications et de réduire la quantité de connexions ouvertes de cette façon. La même application est ensuite capable de servir beaucoup plus d'utilisateurs simultanés avec beaucoup de meilleures performances.
Dans une application importante, il est peu probable que toutes les demandes touchent la base de données car les mêmes informations sont probablement trouvées sur le cache de toute façon.
Dans l'environnement en cluster avec des sessions non collantes, la connexion JDBC ne serait même pas valide si la demande frapperait une autre case que celle où la session a été créée.
En général, vous devez stocker uniquement des informations spécifiques à l'utilisateur dans la session et même réduire le montant requis dans les sessions au minimum. Plus de données en session signifie plus de données à transférer entre les serveurs d'applications dans un cluster lorsque des sessions sont répliquées (en cas de stockage des sessions ne sont pas stockées dans un DB ou un cache central).
Bien que je n'ai aucun moyen de savoir, je suppose que votre collègue a démarré avec chaque demande de récupération d'une nouvelle connexion de son propre responsable, tout comme elle est faite dans les programmes débutants et démo. Il a bientôt découvert que cela a ralenti la demande de façon spectaculaire; Alors maintenant, il évite de créer la création de la connexion en "la mise en commun" dans des sessions utilisateur.
Cela résout le problème de performance des utilisateurs effectuant une 2e et des demandes suivantes sur une connexion, mais c'est une solution très gênante et non évolutive. Si la base d'utilisateurs de votre application augmente, le nombre d'utilisateurs ayant des sessions ouvertes dépasse rapidement le nombre maximal de connexions que votre DB peut vous donner. Ensuite, il y a des problèmes de sessions ou de connexions de DB chronométrant ...
La solution "Standard de l'industrie" consiste à utiliser la mise en commun de la connexion. Les versions modernes de Tomcat ont une mise en commun de la connexion "intégrée", de même que d'autres serveurs d'applications Web. Sinon, vous pouvez facilement installer votre propre. Cela vous permet de gérer complètement un bassin de connexions de manière totalement indépendante des sessions utilisateur.
Un autre avantage de la mise en commun de la connexion est que, une fois que la piscine est "réchauffée", c'est un certain nombre de connexions utilisées et initialisées, même "Premières demandes par session d'utilisateur" reçoivent une connexion rapidement. Donc, le débit global sera amélioré sur votre situation actuelle.
Pourquoi vous ne stockeriez pas une connexion JDBC lors d'une session:
Un pool de connexion peut aider à résoudre les problèmes 1 à 3.
Peut-être devriez-vous nous expliquer pourquoi vous pensez qu'il ne devrait pas le faire en premier?
@ Thorbjørn Je suppose que ma réaction initiale était parce que je ne l'ai jamais vu auparavant. Mais il semble idiot de créer 1000 connexions JDBC pour 1000 utilisateurs ...
Y a-t-il quelque chose de spécial à propos de chaque connexion ou pourraient-ils être facilement regroupés?
Si votre seule préoccupation est la performance, utilisez un pool de connexion. Je vois dans votre historique de questions que vous connaissez Tomcat, voici un lien Comment le faire: tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html
@Ballusc - Je connais bien la mise en commun de la connexion, car c'est ce que j'utilise habituellement, ou laissez simplement le gérer l'orm libère pour moi. Je n'ai jamais vu cela auparavant. Merci néanmoins pour l'info!