Discussion :

[benben02]

Bonjour à tous !

je fais face à un prolème d'utilisation du jpa-toplink dans une configuration multi-tenant où chaque tenant possède son propre schéma, le tout au sein de la meme base.


ce que je veux faire c'est de créer 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 idées ?

Merci

[DevServlet]

Bonjour,
Pourquoi veux tu te passer du fichier de persistence, sachant qu'à l'intérieur tu peux définir 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 idée qui me sembl assez holé holé, c'est d'utiliser un seul schéma , donc un seul Persistence unit dans persistence.xml...

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

qu'en pensez vous ?

[JeitEmgie]

Je viens d avoir une idée qui me sembl assez holé holé, c'est d'utiliser un seul schéma , donc un seul Persistence unit dans persistence.xml...

Mais dedans y'aura des tables spécifiques 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 schémas…

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

si l'on veut implémenter la possibilité d'un schéma dynamique au-dessus de JPA, il faudrait définir une nouvelle annotation et modifier le code qui scanne les annotations (notamment @Table …) pour créer les structures de binding (dans le cas d'Hibernate c'est AnnotationBinder qui est en charge de cette tâche…) pour utiliser cette annotation pour aller chercher la définition du schema de manière dynamique en fonction des paramètres de cette nouvelle annotation… (… et il faudrait encore être certain que les informations dynamiques soient réellement accessibles et à jour lorsque ce scanning a lieu… et que l'accès à ces données ne crée pas de dead lock…)

d'autre part, dans le cadre d'une application multi-tenant, si vous voulez que le schéma soit déterminer 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 créer un entity manager pour le schéma particulier, ce qui devra provoquer le re-scanning des classes, ce qui en retour devrait appeler le code qui détermine le "tenant" en cours…
mais si plusieurs utilisateurs du même "tenant" se connectent en même temps il faut aussi éviter de faire ce travail plusieurs fois…

si par contre le "tenant" est déterminé par l'URL d'accès à 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 impératif de vérifier qu'il y ait bien un gestionnaire de cache par entity manager correspondant à chaque schema (attention au pattern singleton…)
car évidemment des objets de même type avec la même Primary Key mais dans des schémas différents vont coexister en mémoire…

une autre piste pourrait être du côté de @PersistenceContext… mais pas encore eu le temps de creuser… de toute façon cela passerait aussi par une nouvelle annotation et une modification du code injectant l'entity manager sur base de @PersistenceContext…

de toute façon 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 dépendance 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é :

Définir vos POJO de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
@Embeddable
public class ENTITY_X_Base {
  @Column(…)
   …
}

et créer 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 à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
@Entity
@Table(name = "TheTableName", schema="TheSchemaName")
public class EntityClass {
	@Embedded
	protected	ENTITY_X_Base	itsBase;
 
        …
}

(en fait ce sera toujours la même classe, c'est uniquement l'annotation @Table qui doit être changée…)

et utiliser : http://www.dynamicjava.org/projects/dynamic-jpa
(ou s'inspirer du code source pour réaliser le nécessaire…)