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

[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.

[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.

[the_cha0s]

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.

Je ne comprends pas en quoi le SwingWorker me sera utile ? j'ai toujours travailler sans et je n'ai jusqu'à présent eu aucun problème.

[OButterlin]

Donc tu exécutes tes traitements dans l'EDT, ce qui est la pire des habitudes dans les développement Swing, je dirais même : l'erreur de base

Tous les traitements long (ou nécessitant d'autres ressources que les composants graphiques) devraient être fait via les SwingWorkers.

[the_cha0s]

ben tout dépend de ce que tu appelles traitement...
Mes Views ne font qu'afficher les résultat obtenus, les contrôleurs accède à leur champ et les modifient .à part ça je ne vois pas ce que tu veux dire.
tu peux essayer de préciser stp ?

[tchize_]

Tu fais de l'accès base de données, tu fais des query, tu sauve des données, tu écrit des fichiers, tu fais des calculs. Toutes ces opérations doivent être faites ailleurs que dans l'EDT. Dès que ça touche

-> du calcul
-> des IO (disque ou réseau)

ça devrait se faire ailleurs que dans l'EDT.

[the_cha0s]

Tu fais de l'accès base de données, tu fais des query, tu sauve des données, tu écrit des fichiers, tu fais des calculs. Toutes ces opérations doivent être faites ailleurs que dans l'EDT. Dès que ça touche

-> du calcul
-> des IO (disque ou réseau)

ça devrait se faire ailleurs que dans l'EDT.

D'accord j'essaierai d'en tenir compte. Par contre pour ma question principale ? celle concernant les EntityManager pour être exacte ?

[OButterlin]

L'usage à tendance à dire : les 2
Il faut pouvoir partager un entityManager ou en avoir un propre au DAO.
Le premier cas fait référence au partage d'une transaction sur plusieurs DAO (pattern facade), le deuxième, c'est le cas pas défaut, quand on n'en a pas encore...
A noter que pour ça, les EJB via JTA ont un sérieux intérêt

[the_cha0s]

L'usage à tendance à dire : les 2
Il faut pouvoir partager un entityManager ou en avoir un propre au DAO.
Le premier cas fait référence au partage d'une transaction sur plusieurs DAO (pattern facade), le deuxième, c'est le cas pas défaut, quand on n'en a pas encore...
A noter que pour ça, les EJB via JTA ont un sérieux intérêt

ok merci !