Discussion :

[mickael.guilbert]

Bonjour,

Je suis en cours de réflexion sur une application qui doit se connecter sur environ 200 bases (+1 tous les mois) un peu partout en europe via un vpn à 1Mo.

Sur ces bases je n'execute que des procédures stockées.

Actuellement je suis sur une solution pur jdbc, c'est à dire que mon EJB metier
monte une connexion jdbc sur ma base et la ferme en fin de traitement.

Je vais utiliser Glassfich V2 et j'aimerais savoir si vous connaissez une limite dans le nombre de datasources que l'on peut construire, les ressources que cela prends et est ce que pour vous c'est une meilleur solution que le JDBC pur.

Une autre question : Si le connexion VPN tombe, comment se comporte le dataSource ?

J'ai de fortes contraintes de dispo et de stabilité (c'est pour un site internet commerciale)

Merci à vous.

[mickael.guilbert]

voici une réponse (pour info) obtenue sur une autre liste :

Salut,

Je pense que tout dépend de la fréquence à laquelle tu accèdes aux bases.
Avec une solution DataSource tu ne controle pas la fermeture des connexions et tu vas vite te retrouver avec 200 connexions ouvertes alors qu'elles sont inutiles.
Donc en gros :

Si tu effectues des connexions fréquentes à toutes les base tu as interet de mettre en cache des connexion via un datasource.
Dans le cas contraire c'est dommage de mobiliser une ressource TCP pour des connexion inutiles sachant qu'un datasource peut envoyer des requetes "keep-alive" assez fréquemment, donc tout ça * 200 c'est beaucoup.

Par contre si les connexions sont fréquente le bruit réseau requis pour initialiser la connexion va être trop par rapport au signal de ton tranfert de donnée. Dans ce cas une solution datasource ou mise en cache de tes connexion JDBC est interressante.

En gros c'est un peu étudier ton rapport signal/bruit, le signal étant la commande jdbc pour appeler ta proc et le bruit la connexion JDBC (init, keep-alive, deconnexion).

Si ta connexion VPN tombe c'est pas tellement le datasource qui compte mais plutot la fiabilité du drivers JDBC derrière. Pour info j'ai utilisé le datasource Oracle et je devais tester moi-même (via requete bidon) la connexion reçue du pool car il pouvait me renvoyer des connexions obsolètes inutilisables. Un bon driver JDBC est capable de dire au datasource que telle ou telle connexion est inutilisable.

A noter aussi que le driver Oracle n'était pas super-fiable en envirronement multi-thread, évite de partager une connexion dans plusieurs thread.

Sinon si tu ne fais que des appels à des proc peut-être qu'une cnx JDBC n'est pas nécessaire, pourquoi ne pas penser à une architecture du type message? Au lieu d'initialiser des connexions JDBC tu envois des messages du style JMS, tu auras besoin d'un bout de code qui tourne sur chaque serveur Oracle mais cela semble plus adapté vu tes besoins.

Bon courage.

[mickael.guilbert]

si mes bases se nomment base1 ... base201.
si un utilisateur fait appel à 3-4 methodes en moyenne de mon EJB3 metier.

Puis je faire un pool de connexions qui gere une 10ene de connexions bases ?
à partir du quel je peux faire un getConnexion(base69 )
- si la connexion jdbc est monté, j'ai ma connexion
- sinon le pool monte ma connexion et la met dans le pool
- si une connexion n'est pas utilisé pendant N minutes, le pool la ferme.

je suis clair ?