Discussion :

[jecomprendsrien]

Bonjour,

je suis en train de réfléchir à la conception de mon modèle pour une application personnelle. En fait, les utilisateurs de mon application seront scindés en plusieurs bases de données identiques dans leurs structures. Comme je vais utiliser PostGreSQL, je peux aussi choisir de créer une seule base de données mais avec plusieurs schémas. En gros :

BDD1
|_ schéma1
|_ (table_1, table_2, table_n)
BDD2
|_ schéma1
|_ (table_1, table_2, table_n)

OU :

BDD1
|_ schéma1
|_ (table_1, table_2, table_n)
|_ schéma2
|_ (table_1, table_2, table_n)

A priori, je m'orienterais plutôt vers le choix 2 mais sans grandes certitudes...

Dans le cas 1, cela m'oblige à créer plusieurs persistance_units afin de gérer les différentes bases de données mais ensuite c'est moins facile (voir impossible ?) d'utiliser l'injection de dépendance dynamique dans un EJB. On est je pense obligé de créer un EntityMangerFactory puis un EntityManger ce qui est moins rapide que l'injection.

Dans le cas 2, je peux utiliser l'injection de dépendance car je n'ai qu'une seule base de données mais je dois à mon avis effectuer une requête préliminaire avant chaque requête métier afin de choisir mon schéma pour les requêtes à effectuer :

Code :

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

1
2
3
4
 
SET search_path TO schema1;
ou
SET search_path TO schema2;

j'ai vu que l'on peut définir un schema dans le fichier orm.xml mais dans mon cas de figure j'aurais n schemas donc impossible. Suis je condamné à effectuer une "pré-requête" de sélection de schéma ? Via un intercepteur EJB, cela pourrait il marcher ?

Merci de vos conseils et de votre feedback

[DevServlet]

Bonjour,
On peut effectivement gérer plusieurs schémas via JPA,mais il faut bien comprendre que chaque schéma sera chargé dans un contexte de persistence différent. donc t'auras autant d'entityManager que de contexte de persistence déclarés. Sauf erreur de ma part je ne pense pas qu'on puisse changer de schéma dynamiquement, un schéma est chargé au démarrage de ton application et reste en mémoire. Voici un lien qui explique comme s'y prendre

[jecomprendsrien]

Bonjour,

effectivement j'ai vu ce lien mais cela oblige à faire des appels JNDI à chaque fois pour récupérer mon EntityManager aussi ?

Sachant qu'un utilisateur accédera, une fois son compte créé, toujours à la même BDD (si plusieurs BDDs) et au même schéma, serait-il judicieux par exemple de créer un attribut référençant un EntityManager dans un EJB stateful ? Cet EntityManager pourra t-il se désynchroniser de la BDD si l'utilisateur reste trop longtemps connecté ou pour une autre raison obscure...?

Merci

[DevServlet]

Bonjour,

effectivement j'ai vu ce lien mais cela oblige à faire des appels JNDI à chaque fois pour récupérer mon EntityManager aussi ?

Sachant qu'un utilisateur accédera, une fois son compte créé, toujours à la même BDD (si plusieurs BDDs) et au même schéma, serait-il judicieux par exemple de créer un attribut référençant un EntityManager dans un EJB stateful ? Cet EntityManager pourra t-il se désynchroniser de la BDD si l'utilisateur reste trop longtemps connecté ou pour une autre raison obscure...?

Merci

Je ne capte pas trop ton inquiétude, bien sûr que tu auras un objet par entityManager, les opérations de synchro (ou d'autres natures) que tu faisais avec un seul contexte de persistence, tu les feras aussi sur plusieurs objets référençant les entityManager.J'ai pas capté ton souci à vrai dire

[jecomprendsrien]

en fait je ne parle pas de synchro d'une entité quelconque dans la base mais de la synchro du contexte de persistance tout entier. Possible non dans certaines circonstances que mon EntityManager stocké dans un stateful EJB se désynchronise de ma base ? Sachant qu'il sera instancié qu'une fois (au login de l'utilisateur). Dans l'absolu un utilisateur peut resté connecté indéfiniment et mon EntityManager peut dater alors de plusieurs jours...

Je sais pas si l'injection dans un EJB stateless s'effectue à chaque appel de l'EJB ou une seule fois à la création de l'EJB ? Si c'est à la création de l'EJB alors pas de soucis car mon stateful EJB procédera de la même façon par contre si l'injection se fait à chaque appel ca change tout...

Enfin au pire je testerai pas mal de cas de figure

[DevServlet]

en fait je ne parle pas de synchro d'une entité quelconque dans la base mais de la synchro du contexte de persistance tout entier

Je l'avais bien compris,Les 2 synchronisations sont possibles (entité via un merge) et l'entité manager via un flush.

Possible non dans certaines circonstances que mon EntityManager stocké dans un stateful EJB se désynchronise de ma base ? Sachant qu'il sera instancié qu'une fois (au login de l'utilisateur). Dans l'absolu un utilisateur peut resté connecté indéfiniment et mon EntityManager peut dater alors de plusieurs jours...

Ta question trouve sa réponse à un niveau plus haut déjà, je doute fort que dans ton environnement le temps de vie d'une session dépasse une journée, en d'autres termes si on n'a accès à aucun appel serveur, on ne saurait accéder à la base.

Je sais pas si l'injection dans un EJB stateless s'effectue à chaque appel de l'EJB ou une seule fois à la création de l'EJB ? Si c'est à la création de l'EJB alors pas de soucis car mon stateful EJB procédera de la même façon par contre si l'injection se fait à chaque appel ca change tout...

Enfin au pire je testerai pas mal de cas de figure

, A chaque appel d'un EJBStateLess c'est une nouvelle référence qui est créee avec tout ce qui va avec. Pour moi le souci de synchronisation des entités ne devrait pas se poser, puisque chaque action d'un utilisateur (bien sur connecté) sera updaté en base from scratch. Ton souci n'a pas lieu d'être encore une fois.