Discussion :

[ToToR_2000]

Bonjour à tous,

Je crée en ce moment une application d'entreprise qui est fondée sur le modèle 3-tiers classique: client(UI)/serveur/base de données. Les requêtes de l'utilisateur envoyées par le client passent toutes par le serveur et la base ne communique qu'avec le serveur: client <-> serveur <-> base de données. L'application est utilisable au travers du client qui demande à l'utilisateur physique de se connecter avec un compte (càd en pratique de rentrer un login/password). La base stocke dans une table un enregistrement pour chaque compte avec les données qui lui sont associées (notamment des droits d'accès à certaines fonctionnalités du client). Lorsque l'utilisateur physique utilise le client, il y est reconnu grâce au compte qu'il a choisi pour se connecter à l'application.
Jusqu'ici, il me semble que ce schéma est assez classique.

Seulement, afin de pouvoir se "connecter" à l'application au sens défini précédemment, il faut d'abord se connecter à la base pour pouvoir vérifier si le couple login/password entré correspond bien à un compte. Et pour se connecter, il faut un "user" défini au préalable dans la base. C'est ce que j'ai fait jusqu'ici mais à présent, je me rends compte que lorsqu'il y aura N utilisateurs physiques qui se connecteront à l'application, ils auront certes chacun une connexion propre (unique) au serveur, mais le serveur lui n'aura qu'une seule connexion à la base, avec le "user" de la base.

D'où ma question: est-ce une bonne façon de faire ? cela nuit-il aux performances d'avoir une seule connexion (très chargée) à la base plutôt que plusieurs (plus légères) ? Peut-il y avoir un problème de sécurité quelconque ?

Je vous remercie d'avance de vos réponses.

[kain_tn]

Bonjour,

Je ne sais pas quelles technos tu utilises pour ton client et ton serveur, mais a priori, si c'est possible, je te conseillerais plutôt de faire ce qui suit:

Tu gardes les comptes de tes utilisateurs et leurs droits dans la bdd mais c'est ton serveur qui décide (en fonction des droits qu'il lit dans la bdd) de qui a le droit de faire telle ou telle action (tu peux ainsi utiliser des threads ou des sessions par exemple).

Ainsi ton serveur continue de se connecter à la bdd avec un seul utilisateur (mais pas forcément une seule connexion) et en plus selon ta techno tu peux peut-être utiliser un pool de connexions pour éviter de perdre du temps en connexion/déconnexion.

[ToToR_2000]

Bonjour,

Je te remercie de ta réponse.
Avant toute chose, voici les technologies que j'utilise:
C++/Qt/Boost, la connexion client/serveur se fait grâce à la bibliothèque gSOAP et le serveur se connecte avec le module QtSQL à un serveur MySQL.

A vrai dire, je ne connaissais pas le concept de "connection pool" mais après m'être renseigné, je suis assez tenté de l'utiliser dans mon projet. Cependant, j'ai compris que l'un des intérêts principaux était de réduire le temps de connexion/déconnexion comme tu l'as dit, mais il semble que MySQL a justement des temps de connexion/déconnexion beaucoup plus faibles que les autres SGBDR, d'où ma question: le connection pool est-il utile dans mon cas ?

Toujours à propos du connection pool et en lien avec le multithread du serveur, j'ai l'impression que le second est indispensable pour faire fonctionner le premier. Est-ce vrai ?

Enfin, vu les technologies que j'utilise, y a-t-il une méthode standard pour implémenter le connection pool ? Par exemple, pour le connecteur MySQL/Java, il y a un article explicite de MySQL sur le connection pool pour expliquer sa mise en oeuvre mais pas sur C++. Faut-il simplement l'adapter ?

Merci de ton (votre) aide !

[kain_tn]

Cependant, j'ai compris que l'un des intérêts principaux était de réduire le temps de connexion/déconnexion comme tu l'as dit, mais il semble que MySQL a justement des temps de connexion/déconnexion beaucoup plus faibles que les autres SGBDR, d'où ma question: le connection pool est-il utile dans mon cas ?

Eh bien ça dépend combien d'utilisateurs simultanés ton application devra supporter. Personnellement, à moins d'être sur un petit projet, je pense que c'est un plus non-négligeable. Ça peut également servir si tu dois un jour changer de BDD.

Toujours à propos du connection pool et en lien avec le multithread du serveur, j'ai l'impression que le second est indispensable pour faire fonctionner le premier. Est-ce vrai ?

Non, ça dépend beaucoup de la technologie utilisée. Par exemple, avec du PHP, la notion de thread n'a pas de sens (chaque script est exécuté par un fork ou un thread du serveur web mais tu ne peux pas en créer un toi même par exemple). Avec du Java (qui supporte les threads), tu peux aussi créer le pool au démarrage du serveur et ensuite utiliser des sockets asynchrones (système de callback) pour éviter de gérer des threads. Donc je pense que tout dépend de la façon dont tu vas coder ton application.

Enfin, vu les technologies que j'utilise, y a-t-il une méthode standard pour implémenter le connection pool ? Par exemple, pour le connecteur MySQL/Java, il y a un article explicite de MySQL sur le connection pool pour expliquer sa mise en oeuvre mais pas sur C++. Faut-il simplement l'adapter ?

Je n'en ai pas trouvé et je n'ai pas l'habitude de coder ce genre d'appli en c++ (ma connaissance de Qt se limite à l'écriture de clients et non pas de serveurs), mais plutôt en Java avec Apache Commons...

Côté C++ j'ai l'impression que tu vas devoir l'implémenter toi même avec une collection.

Voici quelques liens utiles qui traitent de ce sujet sur les forums de Qt:
ici et ici

[ToToR_2000]

Merci de ta réponse !

En réalité, l'application est déjà codée pour l'essentiel et maintenant que je me suis aperçu du défaut de conception, j'essaie de le corriger. Etant donné les informations que j'ai pu récolter sur le sujet, je pense que je vais ajouter le multithreading au serveur et effectivement implémenter le connection pooling à l'aide de Qt. En cherchant bien, j'ai pu trouver un modèle d'implémentation C++ du connection pooling. Je le mets au cas où quelqu'un aurait le même problème que moi:
http://www.tidytutorials.com/2009/07...ows-clexe.html
Si tu as envie de regarder, je veux bien avoir ton avis sur l'implémentation
Sinon, je te remercie pour ton aide !

[kain_tn]

Si tu as envie de regarder, je veux bien avoir ton avis sur l'implémentation
Sinon, je te remercie pour ton aide !

Oui, je veux bien jeter un œil à l'implémentation.

Sinon je crois que le lien que tu voulais mettre plus haut est celui-ci: http://www.tidytutorials.com/2009/07...base-pool.html