JPA avec plusieurs BDD

bonjour,

dans le cadre d'un projet je voudrais savoir si il était possible de crée et d'utiliser plusieur base de donnée avec des noms différents mais avec les structure identique .

exemple simple un client viens me voir pour avoir sa base de donnée client j'aimerais crée via l'interface web de mon site sa db du genre jean-DB ensuite j'ai un autre client qui viens et crée sa dj pierre-db.
toujours sans avoir toucher au code .

lorsque mon application se lance pouvoir choisir sur quel db il dois se conecter .


pouvez vous me dire si c'est possible ? pouvez-vous m'aider pour un projet exemple.

j'utilise maven avec web-service .

D'avance Merci :)

Bonjour,

JPA n'est pas conçue pour ce type d’opération. C'est une api qui n'est pas cénsee connaitre la base de donnée sur laquelle elle doit travailler, notion de fort découplage, car créer une base de donnée à chaud c'est forcément connaître de quel SGBD il s'agit. Ceci dit je pense qu'il y'a un problème de conception dans ton approche. Peut on savoir précisément quel es ton besoin fonctionnel ? Car si ça se trouve en restant dans la même bd suivant une bonne conception du modèle cela pourrait répondre au besoin. Alors ?

Si tu souhaites lister les bases de données sur un serveur, tu peux utiliser JDBC. ça doit être quelque chose comme:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// ... String jdbcUrl = "jdbc:postgresql://localhost:5432/postgres"; Connection connection = DriverManager.getConnection(jdbcUrl, "postgres", "****");   DatabaseMetaData meta = connection.getMetaData(); ResultSet res = meta.getCatalogs();   // Extraire la liste des bases du resultSet   // ...

---

À adapter à ton SGBD et tes besoins.

Disons que ça va dépendre de ta base de données et de la méthode utilisée pour initialiser tes connexions.
Si je comprends bien, c'est une notion de "schéma" spécifique par client que tu veux gérer.
Pour ça, tu as l'url de la base de données qui permet de spécifier sur quel schema tu travailles.
Avec MySQL, tu aurais quelque chose comme ça

Code:

---

jdbc:mysql:///le_nom_schema

---

Ensuite, il suffit de ne pas spécifier l'attribut "schema" dans tes entities comme ceci

Code:

---

1 2 3 4 5 6 7

@Entity @Table(name = "DECIDEUR", schema = "PIDDLIB") public class Decideur implements java.io.Serializable { ... }

---

je vais essayer de mieu m'exprimer :

l'administrateur le patron de ma société cree un evenement pour un client :

il a une interface html /angular qui se conecte au web service /jpa

il rentre le nom du client : ex client1
choisi les autres parametres et clique sur envoyer

ce que je veux faire en black-end :

dans ma table parametre :

un insert avec nom de la db / url /login /password .....
exemple db_Client1 / www.siteduparton.com/Client1 root root .....

jusque la je sais tout faire

ensuite j'aimerais avec jpa coté admin qu'il me fasse un peu l'equivalent du code suivant
crée db db_client1
crée table client (les champs )
crée table article (les champs )
etc

voila pour la partie admin

partie client le client rentrer www.siteduparton.com/Client1
il utilise le site web avec les fonctionalité pour donnée une idée :

importation de son fichier exel avec sa liste de client pour les inviter a l'évenement
modification de sa propre base de donnée.
création de ses formulaire d'inscription pour l'evenement etc
ce qui peu être volumineux trop volumineux si je stoque tout ses choses la sur la même db apres plusieur année

mon souci ici est de dire a l'entity manager ecouter tout le programe pour l'url client1 tu dois te conecter à la db client 1

https://docs.jboss.org/hibernate/orm...html/ch16.html

merci je vais essayer ca et si j'ai des problème je vous demanderais

j'ai un peu de mal a voir comment faire Separate database avec jpa pouvez-vous m'aider?

Comment acquiers-tu la connexion dans ton code ?

bonjour,

voici le code de base comment y ajouter le Multi-tenancy

https://www.dropbox.com/s/asbntqjew4...oject.zip?dl=0

Bon, je n'ai jamais eu à faire ça mais je travaillerais sur la méthode getEntityManager() pour différencier.
En gros, si les clients sont connus d'avance, tu peux définir plusieurs persistenceUnit dans ton fichier persistence.xml et renvoyer la bonne PU en fonction du client connecté.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">   <persistence-unit name="client1" transaction-type="JTA"> <jta-data-source>client1</jta-data-source> <properties> <property name="hibernate.default_schema" value="SCHEMA1" /> </properties> </persistence-unit>   <persistence-unit name="client2" transaction-type="JTA"> <jta-data-source>client2</jta-data-source> <properties> <property name="hibernate.default_schema" value="SCHEMA2" /> </properties> </persistence-unit>   </persistence>

---

bonjour,

malheureusement je ne connais pas les clients a l'avance il sont stoquer en db et ajouter de facon dynamique

Via l'EntityManagerFactory, tu pourrais récupérer des connexions différenciées, regarde ceci.

Mouais, tu as vraiment des millions d'entrées dans tes tables que tu ne peux pas te permettre de partager avec une colonne supplémentaire "clientID" ?

Parce que créer un persistence unit, c'est créer les caches, la structure d'analyse des entités, le connection pool. Ca peux tenir la route d'en faire un par client si t'as juste une dizaine de clients.
Démarrer un entitymanager est lent -> Tu peux pas te permettre de le faire à la volée sur chaque connection.
Les garder occupe de la mémoire -> tu ne peux pas te permettre d'en avoir une centaine.
Une DB ça occupe de l'espace disque (minimum 50M avec Mysql, 100 clients = 5G de vide à conserver)
Tu as besoin de créer un pool sur chaque DB. 100 clients, connection pool de 10 -> 1000 connections actives à la DB...


Tu évalue la DB / client à quelle taille sur le long terme?
Tu compte gérer combien de clients?
Quelles ressource (mémoire / cpu / stockage) tu peux allouer par client?


Mon avis est que si tu commence à faire un persistence unit / client, autant faire un déploiement par client, ce sera plus propre.

Tu évalue la DB / client à quelle taille sur le long terme? facilement stoquer plus de 200 000 information par table
Tu compte gérer combien de clients? des client a l'année et d'autre le temps de 3 ou 4 mois
Quelles ressource (mémoire / cpu / stockage) tu peux allouer par client? les serveur pas pour moi (admin reseau )
que me conseille tu ?

j'ai essayer le code suivant :

Map<String,String> properties = new HashMap<String, String>();
properties.put(JDBC_DRIVER,"com.microsoft.sqlserver.jdbc.SQLServerDriver");
properties.put(JDBC_URL,"jdbc:sqlserver://localhost:1433;databaseName=Config");
properties.put(JDBC_USER,"sa");
properties.put(JDBC_PASSWORD,"1234");
EntityManagerFactory fem ;
fem = Persistence.createEntityManagerFactory("Config");
return fem.createEntityManager();

j'ai le message d'erreur javax.persistence.persistenceException no persistence provider for entityManager named config

pouvez-vous m'aider ?

Citation:

---

Envoyé par mimi6060

que me conseille tu ?

---

De voir avec l'admin réseau ce qui est prévu. Pas besoin de rentrer dans les détails immédiatement avec lui. Mais tu ne va pas développer de la même manière si tu dois gérer 50 clients sur 8 cores ou si t'a un budget mensuel de 500 euros / client. Ca c'est à l'architecte et à l'admin de déterminer ce qui est faisable avec le commercial. Ce n'est pas en bout de course quand tout sera développé qu'il faudra se rendre compte que l'application traine la patte, qu'elle coute 2 fois plus cher qu'elle ne rapporte ou que l'architecture n'est pas scalable comme l'on veux.

Pour résumé, tes possibilités actuellement sont:

• 1 persistence / client: compliqué à coder (tu va t'assoir sur la plupart des mécanismes d'injections d'Entitymanager / de transaction / de datasource) et tu va galérer sec selon moi
• 1 application par client: facilement scalable (on peux même mutiplier les serveur DB au besoin), mais il faut pouvoir allouer une appli J2EE par client. Une appli ça prends plus de place qu'un entitiManager
• 1 serveur par client, par exemple du elastic amazon ou des noeuds chez google: avantage le cout est fixe en fonction de l'usage, le démarrage d'un nouveau client est facile. Inconvénient: ce cout peut être plus élevé qu'une architecture centralisée
• Travailler proprement dans ton code, bien optimiser tes requêtes SQL et tu devrais pouvoir avec ta description facilement mixer une 50aines de clients dans la même DB voir bien plus.

Une base de donnée correctement optimisée avec les bons index et des requête SQL bien travaillée fonctionne très bien avec des centaines de millions de record. Là où je bosse, on commence à avoir des problème sur certaines requêtes pas faisables. On parle de traiter des milliard de records et ce sont les requêtes sans index qui posent problème :) Alors 200.000 lignes, c'est peanuts pour un SGDB!

le patron veux absolument 1 db par client et pouvoir crée cette db apartir d'une interface web et conecter le service web sur la db qu'on vient de crée quand le client tape son url .
en gros le même service web mais avec chaque client sa db pas possible de faire ca avec l'entity manager?

Sans plus d'information, j'opterais pour dupliquer le bloc DataSource - EntityManager - WAR / client.

L'interface d'admin aura juste à déployer un nouveau war dans le conteneur jboss à chaque fois que l'on crée un client et à le retirer quand on retire un client. Il auront chacun leur contexte et leur URL, pas de mélange possible. Possibilité de faire du scaling facilement en multipliant les conteneurs J2EE.

Citation:

---

Envoyé par tchize_

Mouais, tu as vraiment des millions d'entrées dans tes tables que tu ne peux pas te permettre de partager avec une colonne supplémentaire "clientID" ?

Parce que créer un persistence unit, c'est créer les caches, la structure d'analyse des entités, le connection pool. Ca peux tenir la route d'en faire un par client si t'as juste une dizaine de clients.
Démarrer un entitymanager est lent -> Tu peux pas te permettre de le faire à la volée sur chaque connection.
Les garder occupe de la mémoire -> tu ne peux pas te permettre d'en avoir une centaine.
Une DB ça occupe de l'espace disque (minimum 50M avec Mysql, 100 clients = 5G de vide à conserver)
Tu as besoin de créer un pool sur chaque DB. 100 clients, connection pool de 10 -> 1000 connections actives à la DB...


Tu évalue la DB / client à quelle taille sur le long terme?
Tu compte gérer combien de clients?
Quelles ressource (mémoire / cpu / stockage) tu peux allouer par client?


Mon avis est que si tu commence à faire un persistence unit / client, autant faire un déploiement par client, ce sera plus propre.

---

NB

Citation:

---

DISCRIMINATOR
Correlates to the partitioned (discriminator) approach. It is an error to attempt to open a session without a tenant identifier using this strategy. This strategy is not yet implemented in Hibernate as of 4.0 and 4.1. Its support is planned for 5.0.

---

La solution la plus simple reste le SaaS : déploiement d'une VM complète par client.