Discussion :

[the_cha0s]

bonjour,

j'ai juste une petite question : si on gère un seul schéma de BD est ce que pour toutes les tables on peut travailler avec un seul "EntityManager" ou chaque DAO qoit avoir son propre EntityManager ?

[OButterlin]

Si on devait faire une équivalence, ça consisterait à demander si on peut gérer toutes les requêtes à une base de données par un seul objet Connection...
De mon point de vue, c'est possible... mais absolument pas recommandé

La question est tellement surprenante que je me demande si tu ne confonds pas EntityManager et PersistenceContext...

[the_cha0s]

Je débute en JPA 3 jours d'ancienneté !!
mais en ce qui concerne la comparaison que t'as faite moi j'ai toujours eu l'habitude de créer une Connection au niveau du controller avec une instance unique (Singleton) ce qui me permettait de travailler sur une même connexion (très utile dans le cas où on a des traitements atomiques).

Donc si j'ai bien compris je n'aurais aucun problème si je centralise l'Entity Manager ? c'est ça ?

En fait là actuellement j'ai mis un seul EntityManagerFactory pour tous les DAO, mais dans chaque méthode des des classes DAO j'instancie un nouveau EntityManager et c'est ce qui me semble un peu lourd et non optimale.

[OButterlin]

Juste une question, c'est quel type d'application ? Client lourd ou application web ?

Pour un client lourd, oui, on peut créer une seule connexion et l'utiliser tout au long du cycle de vie, cependant, il faut se méfier :
- du nombre maximum de statements liés
- du contrôle de validation qui peut être différent en fonction des cas d'usage
- etc...

Pour un client web, la question est plus facile à trancher, on ne devrait jamais conserver une connexion plus que le temps de la méthode qui la nécessite.

Bref, en ce qui me concerne, je préfère :
- créer
- utiliser
- nettoyer
- fermer

[the_cha0s]

Juste une question, c'est quel type d'application ? Client lourd ou application web ?

Pour un client lourd, oui, on peut créer une seule connexion et l'utiliser tout au long du cycle de vie, cependant, il faut se méfier :
- du nombre maximum de statements liés
- du contrôle de validation qui peut être différent en fonction des cas d'usage
- etc...

Pour un client web, la question est plus facile à trancher, on ne devrait jamais conserver une connexion plus que le temps de la méthode qui la nécessite.

Bref, en ce qui me concerne, je préfère :
- créer
- utiliser
- nettoyer
- fermer

C'est un client lourd et il n y aura pas d’accès multiThread, chaque User à sa propre base de donnée même si elle est identique à celles des autres.
donc là je devrais mettre par exemple pour une classe donnée : un seul EntityManager qui va gérer ses opérations ou chaque opération va ouvrir un nouveau EntityManager et le fermer par la suite ?? quelle sera la manière la plus optimale et la plus propre ?

[tchize_]

A moins qu'elle soit console, tu aura d'office du multithread. Ne serait-ce parce que tu ne fera pas les opération DB, qui sont potentiellement longue, dans le thread graphique (car ça c'est pas bien) donc tu va utiliser des swingworker, et chaque swingworker a son propre thread.

[tchize_]

Jmoi j'ai toujours eu l'habitude de créer une Connection au niveau du controller avec une instance unique (Singleton) ce qui me permettait de travailler sur une même connexion (très utile dans le cas où on a des traitements atomiques).

Même si ils sont atomique, tu va avoir un problème quand deux thread essaieront d'utiliser le même objet connection simultanément. Cet objet n'est pas multithread safe. Dans une application web, tu est par nature dans un environnement multithread, donc à ne jamais faire. Comme dit OButterlin, un entitymanager par opération utilisateur, qui a en général une duré de vie de quelques centièmes à quelques dixièmes de second maxiumum.