Modification de la datasource dans les services

Bonjour,

J'ai une application configurable par la base de données, ce qui rend fastidieux en temps le fait de rajouter des elements sur l'application puisque parfois cela necessite de faire plusieurs dizaines de requetes.

Pour parer à cela j'essaie de produire une application qui va me permettre de configurer l'appli par une interface graphique ... ce qui permets de ne pas taper les requetes en base de données directement et reduit de maniere caracteristique le risque de mauvaise configuration en base.

Mon probleme est le suivant, j'aimerai produire cette appli pour plusieurs environnement, plus precisemment: la base de developpement, d'integration et de production.

J'ai donc une appli Spring MVC en trois couches WEB-Business-Integration, avec des services business transactionnels, une couche d'integration pluggué sur un framework OR iBatis....

Mon problème est que pour un écran j'aimerai choisir ma base de données sur laquelle faire l'opération, hors mes services sont des singletons et sont configurés par spring. Généralement ils ont donc une référence vers la datasource declrée elle aussi dans le fichier de configuration spring.

Mais j'aurai donc a terme plusieurs datasource de configurée dans le fichier de configuration Spring et je ne sais laquelle mapper puisque ce sera l'utilisateur qui fera se choix ... pour parer a cela j'avais pensé mettre en place un intercepteur de requete dans la couche web ... mais comme mes services sont des singletons ... ce n'est pas possible a moins de modifier la BDD pour tout les threads utilisant le service en question ....

L'autre solution bourine est de faire un transaction manager et un mapping iBatis pour chaque datasource mais je m'y refuse trop louche comme solution ...

Si quelqu'un a une id donc ?.... elle est la bienvenue ... ;)

Merci.

CG...

Peut etre une idee qui me viens si je surcharge les classes de spring et que je redefinie le getDatasource() ca devrait le faire non ?

je ne suis pas sûr de ton problème car tu parles de plusieurs environnements dev, intégration, production. Est-ce par rapport à ces différents environnements que tu veux pouvoir changer de datasource au niveau du client ?

sinon, regardes la notion de "factory-method"

Code:

---

1 2 3

<bean id="exampleBean" class="examples.ExampleBean2" factory-method="createInstance"/>

---

cela te parmet de retourner un bean via l'invocation d'une méthode.
A toi de configurer, dans l'exemple précédent, le bean exampleBean pour qu'il retourne le bon DAO en fonction du choix de l'utilisateur.
Mais vu ton problème, que je n'ai pas encore compris complètement, je ne suis pas certain que cela soit la bonne réponse.

Je récapepette ... ;) ... en fait j'ai une interface (fin je voudrai) ou l'utilisateur peut choisir sur quelle base de données faire la modification.

Or j'utilise un transaction manager pour regler le probleme d'acces concurrent sur ma base de donnée (org.springframework.jdbc.datasource.DataSourceTransactionManager) et du coté intégration j'ai un framework iBatis donc du coup également dans le fichier de configuration spring la classe (org.springframework.orm.ibatis.SqlMapClientFactoryBean).

ces deux classes sont donc deux beans dans mon fichiers de conf spring qui prennent en propriété une reference vers un bean qui est le datasource.

la config classique se fait dans le fichier spring et comme ces deux beans sont des singletons, tout les threads pointent le meme datasource.

or moi je voudrais que chaque Thread la datasource soit une des trois existantes ce choix etant fait par l'utilisateur ....

du coup je pensais surcharger les deux classes spring ci dessus ... redefinir getDataSource et ajouter une proprieté de type ThreadLocal en public static. En rajoutant un intercepteur entre mon dispatcher et mon controller, je recupere l'element du formulaire qui me permets de reperer le choix de l'utilisateur et ensuite je set dans le membre Threadlocal de mes deux classes spring surcharger la valeur choisie.... il me reste plus ensuite qu'a remonter le bon datasource depuis le context applicatif dans la methode getDatasource surchargée ....

Je sais pas si c'est plus clair si cela ne l'est pas n'hésite pas à me poser des questions ... :)

Je sais pas si ma solution envisagée est propre mais je la trouve pas mal, par contre je ne saurais dire si il se peut qu'il y ai un hic car je n'ai pas beaucoup d'experience avec spring mais je me soigne .... lol :mouarf:

Merci ...

CG

je réitère ma question
Ne penses-tu pas que tu mélanges une réelle problématique d'accès multi-bases et une problématique de cycle de développement ?
Je veux dire que comme tu parles d'environnements de développement, intégration et production, la solution réside avant tout dans le déploiement des parties serveur et client.
Il y a autant de serveurs que d'environnements et au niveau du client autant de "clients" que d'environnements. Dans chaque environnement client ou serveur, c'est la config qui change.
Un client "développement" accède à un serveur "développement", un client "intégration" accède à un serveur "intégration",...

Je ne pense pas car c'est une application utilitaire interne qui est sensé nous aider a configurer ces divers environnements justement ...

Ce n'est pas une application qui part en production, en fait c'est plus un outil utilitaire pour l'équipe de développement, elle sera a terme hebergé par un seul serveur ...

Ce qui est bien justement je trouve c'est de pouvoir modifier les données dans les trois environnements au sein de la même application ....

Je sais pas si c'est très clair ...

CG

PS: Que penses tu de la solution que j'ai émise ?

ok mais ne peux-tu pas déployer 3 serveurs, chacun pointant vers sa base de données et au niveau du client, tu n'as plus qu'à choisir le nom du serveur ou le couple (serveur, port). C'est plus simple et tu n'as pas à modifier ton code pour des problèmes de choix de base un peu complexe.
Perso, c'est ce que je ferai.

c'est un peu embetant parce que je souhaite laisser le choix a l'utilisateur pour la cible sur laquelle il veut faire son action et ca fait plutot parti du formulaire ... non d'un choix initial ... d'ailleurs il se peut qu'il veuille reproduire la meme operation de suite sur deux des trois bases ... du coup c lourd il est obligé de changer de webapp et de serveur du coup ... on ne peut pas garder simplement sa saisie en session ...

fin cela me parait pas tres ergonomique de lui faire faire un choix initialement ...
alors qu'en fin de compte c'est juste une cible qui change .. pourquoi faire trois fois l'appli sur trois serveurs ? si tu prends le parallele de services contextuel c'est le meme probleme et tu ne mets pas en place plusieurs appli (une pour chaque services ...)

Fin je sais pas ... je trouve qu'il y a plein d'avantages de pouvoir choisir la cibre de BDD dans le formulaire directement ...

CG

Fin c'est vrai que c'est pas habituel ... mais il faut voir l'appli comme un outil et non comme une application unibase qui est deployée dans trois environnement ... fin après je sais pas je me trompe peut etre ... :)

CG

Mais le choix peut se faire côté client.
Le seul truc c'est que c'est effectivement au niveau du formulaire que l'utilisateur choisi sa cible et c'est côté client que l'on a l'intelligence de savoir quel serveur appeler. C'est simplement un question de connexion au bon serveur.
Donc.......

Côté client
- tu as 3 "jndi templates", un pour dév, un pour intégration et un pour production.
- Pour chaque service de nom "serviceX", tu as en fait 3 beans : devServiceX, intServiceX et prodServiceX. Chacun utilisant le JndiTemplate approprié.
- Au niveau de tes contrôleurs graphiques, tu récupères l'environnement choisi par l'utilisateur et tu choisi le bon service. Pour faire ce choix, tu as plusieurs possibilités. Tu as en dur 3 beans "services" que tu configures dans appContext avec les 3 services précédents; ou tu as une map dont la clé est l'environnement et la valeur un des 3 services précédents. Dans ce second cas, la confi est faite dans appContext mais c'est plus souple que 3 beans en dur dans le contrôleur. Tu as aussi le choix de donner un nom de service au contrôleur ("serviceX dans notre cas) puis de fournit un mécanisme pour aller chercher le bon bean "<environnement choisi>serviceX" dans la factory.

Côté serveur

- Tu as 3 instances de serveurs
- Pour chaque serveur tu n'as qu'un seul type d'accès à la base appropriée

Cette solution me parait plus propre car les effets de bord seront sûrement mieux maitrisés et aussi car donner accès à 3 types de bases totalement différentes au sein du même serveur c'est à la fois dangereux et parfois impossible (pas de visibilité d'une base de dév sur environnement de prod par exemple).

Bref, je reste sur ma solution 3 serveur, 1 client qui switch mais qui connait les 3 serveurs.

mais donc tu es obligé de faire une duplication d'instance de tes services un pour chaque base de donnée ...

C'est cela que je trouve bof .. je trouve que c'est une solution a moindre cout ... parce que moi j'ai 6 datasources en tout et du coup si je fais cela ... ca me fait 6 transaction manager, 6 mapping sql iBatis ... au passage mes dao ... bah je peux pas injecté les mapping iBatis puisque je ne sais pas lesquels l'utilisateur va utiliser ... puis autant de service puisque ce sont des dynamiques proxy qui utilise le transactionmanager ... du coup ca me fait une configuration enorme si j'ai bien compris ... pour tourner sur un seul serveur ...

a moins d'avoir trois serveurs et d'avoir trois webapp qui tourne mais dans ce cas je ne peux pas faire une action sur la 1ere base (1er serveur) et faire la meme sur la 2eme base puisque c'est sur un autre serveur ...

Ajouter une variable locale au Thread me semblait plutot judicieux et pas vaseux du tout puisque c'est justement lié au Thread donc safe dans le fonctionnement ... cette variable permet de definir le contexte donc la bdd sur laquelle taper ...

Je vois justement pas ce qui pourrait y avoir comme probleme dans cette idee ... c'est que ca sorte des sentiers battus qui te gene ego ?

Merci ... ;)

CG

il s'agit bien de 3 webapp, oui.
si ta problématique, que tu ne m'a toujours pas précisé, est bien liée à la notion d'environnement / cycle de développement, je trouve que c'est ta solution qui n'est pas adéquate.
Ce n'est pas "normal" d'avoir une application (ta partie serveur) qui gère plusieurs environnements quand ces environnements sont liés au cycle de développement.

Peux-tu me préciser ton problème et non ta solution ?

Pour la configuration "énorme", je ne vois pas ce que tu veux dire.
Tu dois avoir la même configuration pour tes 3 webapp avec une seule différence = un fichier de propriétés dont la valeur des propriétés change en fonction du contexte ( = en fonction de la webapp). Ces propriétés sont utilisées pour paramétrer les paramètres de définition de ta datasource.