# Java > Gnral Java > Persistance des donnes >  JPA et multi-tenant

## benben02

Bonjour  tous !

je fais face  un prolme d'utilisation du jpa-toplink dans une configuration multi-tenant o chaque tenant possde son propre schma, le tout au sein de la meme base.


ce que je veux faire c'est de crer plusieurs entitymanagers , et selon l'utilisateurs je ferai appel  la bonne entitymanager.

j'ai essai de le faire au runtime, mais je ne vois pas comment se passer du persistence.xml

des ides ?

Merci

----------


## DevServlet

Bonjour,
Pourquoi veux tu te passer du fichier de persistence, sachant qu' l'intrieur tu peux dfinir plusieurs contextes de persistences , et donc charger les em pour tous ces contextes?
Peux tu repreciser ton pb sinon?

----------


## benben02

au fait les tenants y en aura plusieurs et a augmentera du coup, je veux pas  chaque fois changer dans le fichier de persistence

----------


## benben02

Je viens d avoir une ide qui me sembl assez hol hol, c'est d'utiliser un seul schma , donc un seul Persistence unit dans persistence.xml...

Mais dedans y'aura des tables spcifiques pour chaque tenants du genre XXX_table1,YYY_table2, ....

qu'en pensez vous ?

----------


## JeitEmgie

> Je viens d avoir une ide qui me sembl assez hol hol, c'est d'utiliser un seul schma , donc un seul Persistence unit dans persistence.xml...
> 
> Mais dedans y'aura des tables spcifiques pour chaque tenants du genre XXX_table1,YYY_table2, ....
> 
> qu'en pensez vous ?


JPA ne supporte pas les noms dynamiques ni pour les tables, ni pour les schmas

cela se comprend assez facilement si l'on visualise bien que les structures de donnes permettant l'association entre les POJOs et le schma relationnel sont construites lors du scanning des annotations suite  l'analyse de la configuration et non lors de chaque invocation des mthodes de l'entity manager ( ce qui sous-entendrait d'ailleurs qu'on ne le court-circuite jamais dans le code)

si l'on veut implmenter la possibilit d'un schma dynamique au-dessus de JPA, il faudrait dfinir une nouvelle annotation et modifier le code qui scanne les annotations (notamment @Table ) pour crer les structures de binding (dans le cas d'Hibernate c'est AnnotationBinder qui est en charge de cette tche) pour utiliser cette annotation pour aller chercher la dfinition du schema de manire dynamique en fonction des paramtres de cette nouvelle annotation ( et il faudrait encore tre certain que les informations dynamiques soient rellement accessibles et  jour lorsque ce scanning a lieu et que l'accs  ces donnes ne cre pas de dead lock)

d'autre part, dans le cadre d'une application multi-tenant, si vous voulez que le schma soit dterminer en fonction du login, il faut aussi bien voir qu'il vous faudra un entity manager commun pour assurer le login
(les tables servant  l'authentication des "tenants" ne pouvant tre dans un schema particulier  un tenant)
une fois le login effectu, il faut crer un entity manager pour le schma particulier, ce qui devra provoquer le re-scanning des classes, ce qui en retour devrait appeler le code qui dtermine le "tenant" en cours
mais si plusieurs utilisateurs du mme "tenant" se connectent en mme temps il faut aussi viter de faire ce travail plusieurs fois

si par contre le "tenant" est dtermin par l'URL d'accs  la WebApp on peut ventuellement se passer d'un entity manager "commun"

dans tous les cas, il faut bien se rendre compte des ventuelles complications que cette situation peut induire sur la gestion de la cache :
il est impratif de vrifier qu'il y ait bien un gestionnaire de cache par entity manager correspondant  chaque schema (attention au pattern singleton)
car videmment des objets de mme type avec la mme Primary Key mais dans des schmas diffrents vont coexister en mmoire

une autre piste pourrait tre du ct de @PersistenceContext mais pas encore eu le temps de creuser de toute faon cela passerait aussi par une nouvelle annotation et une modification du code injectant l'entity manager sur base de @PersistenceContext

de toute faon rien ne sera simple et il faut s'attendre  de grosses modifications du code (la chasse au pattern singleton dans les DAO/Repositories/Services/Facades qui induirait une dpendance sous-entendue au schema)

et il n'est exclus de devoir retourner au mapping par XML pour supporter ce genre de dynamisme (sans que cela simplifie quoi que ce soit en ce qui concerne la gestion des caches et du reste)


Autre possibilit :

Dfinir vos POJO de la manire suivante :


```

```

et crer vos classes dynamiquement avec un byte code generator et en mettant le bon schema dans l'annotation @Table
votre ENTITY class si elle tait cr " la main" ressemblerait  :


```

```

(en fait ce sera toujours la mme classe, c'est uniquement l'annotation @Table qui doit tre change)

et utiliser : http://www.dynamicjava.org/projects/dynamic-jpa
(ou s'inspirer du code source pour raliser le ncessaire)

----------

