Persistence Unit dynamique

Salut à tous :)

J'ai un petit problème conceptuel quant à la persistence unit. J'en ai définies deux à l'intérieur de mon xml de configuration et j'aimerais pouvoir choisir dynamiquement à l'éxecution laquelle je souhaite utiliser. Pour ce faire, c'est assez simple, cf ce billet que j'ai écrit il y a quelque temps.

La question qui se pose : est-ce correct de procéder comme cela ? Est-ce conceptuellement juste ou cela est-il déconseillé (sécurité, performances, ...) ? Quelles seraient les autres possibilités ?

Merci d'avance de me faire part de vos expériences :)

@++

Citation:

---

Envoyé par thecaptain

Salut à tous :)

J'ai un petit problème conceptuel quant à la persistence unit. J'en ai définies deux à l'intérieur de mon xml de configuration et j'aimerais pouvoir choisir dynamiquement à l'éxecution laquelle je souhaite utiliser. Pour ce faire, c'est assez simple, cf ce billet que j'ai écrit il y a quelque temps.

La question qui se pose : est-ce correct de procéder comme cela ? Est-ce conceptuellement juste ou cela est-il déconseillé (sécurité, performances, ...) ? Quelles seraient les autres possibilités ?

Merci d'avance de me faire part de vos expériences :)

@++

---

sujet intéressant… : même en dehors de l'aspect "changement dynamique à l'exécution", la gestion des plusieurs PU dans une même application est un sujet qui mériterait à lui seul une note dans la FAQ…

c'est d'ailleurs plus courant de devoir gérer plusieurs DB que de devoir changer dynamiquement…
d'ailleurs, quelle est la contrainte qui vous pousse vers cete solution ?
seulement "pouvoir complètement rendre son programme indépendant de la base de données" ?
…



"est-ce correct ?" …

peut-être dans certaines situations… mais je doute que cela fonctionne bien dans tous les types de situations… (et donc il serait intéressant de lister les incompatibilités s'il y en a ou au fur et à mesure de leur découverte…) l'exemple que vous donnez sur le site astomr.ch soulève des questions…

vous spécifiez notamment

Code:

---

<exclude-unlisted-classes>false</exclude-unlisted-classes>

---

dans les 2 PUs…
ce qui signifie que l'ORM va scanner toutes les classes vis-à-vis des 2 DBs sous-jacentes… (aussi bien dans la phase génération de DDL qu'au test effectué au chargement…)
quelles conséquences ?
par exemple si les 2 DBs sont incompatibles sur certains types de données (d'un côté ORACLE, de l'autre MySQL ou PostgreSQL et des BigDecimal au milieu…)
(je suppose que dans votre cas que ce n'est pas le cas et que les 2 DBs sont similaires, ce qui est déjà une particularité à noter et qui le distingue du cas général "plusieurs PUs dans un même projet"…)


votre gestion transactionelle ne peut se faire par @Transactional… cette annotation est incompatible avec plusieurs PUs dans un seul persitence.xml…
donc comment gérez-vous les transactions dans ce projet ?
est-ce que vouloir faire des modifications dynamiques de EM n'entraîne pas des restrictions dans ce domaine ?

idem vis-à-vis de @Secured lorsque la source des logins est une table de la DB (donc dépendant du même RDMBS sous-jacent à l'EM…)… : conséquences ? (notamment vis-à-vis de la chaîne d'appel vers le point où le switch est exécuté…)


est-ce qu'il n'est pas plus simple/plus stable d'avoir 2 jars séparés utilisés comme librairie par un code qui assure le changement dynamique non pas un niveau de l'EM mais un niveau du DAO/Repository ou au niveau d'une couche Service ?

si l'on veut 1 seul jar, alors 2 packages distincts implémentant des interfaces communes et le changement dynamique toujours au niveau de la couche DAO ou Service ? (et en utilisant <class> et <exclude-unlisted-classes>true</exclude-unlisted-classes> dans chaque PU du persistence.xml…)

quelles conséquences en ce qui concerne les caches d'entity ? quels tests avez-vous fait pour démontrer que la technique est sûre de ce point de vue ?

etc…

Salut,

Merci pour la réponse et désolé de revenir si tard :)

Dans l'état actuel des choses, nous envisageons cette solution car nous avons une BDD en production et une BDD de test. Dans les deux cas, la BDD est identique ainsi que les procédures et autres.
Etant donné que le client de test n'utilise que les webservices pour effectuer un workflow, l'idée était de switcher de PU au lancement des tests pour que les assertions de données puissent être correctes.
La seule chose qui change en fait, c'est le nom de la base de données (bdd - bddtest).

Pour ce qui est des transactions @Secured et @Transactional, nous n'en avons pas utilisé, du coup je ne pense pas que cela entre en compte. Et pour les tests de performance, nous n'en avons pas fait non plus, nous tâtonnons pour l'instant :)

Donc pour résumé : je cherche à savoir si l'on peut dynamiquement définir le nom de la BDD au runtime en utilisant une Persistence Unit.

Merci d'avance !

@++

Bonjour,

Désolé de déterré ce vieux sujet, mais je me pose exactement la même question.
Dans mon cas, nous utilisons JPA pour discuter avec une base de données Access et bien sûr le client souhaite pouvoir "choisir le fichier Access à ouvrir".

Avez vous trouver une solution à votre problème ?

Depuis que je cherche, je suis tombé sur :
http://www.dynamicjava.org/projects/dynamic-jpa
qui semble intéressant mais qui semble imposer de connaitre à l'avance les différentes bases vers lesquelles se connecter.

Une idée ?

Salut,

J'avais trouvé la solution. Par contre pour que le client puisse choisir... ça risque d'être compliqué, à moins qu'il n'y ait que quelques bases au préalablement définie, auquel cas tu peux les prédéclarer.

@++