Persistance Best Practice

Bonjour à tous.

Ma question aujourd’hui n'est pas technique (enfin pas vraiment) mais plutôt sur la bonne manière de faire.

Je pose rapidement le cadre du projet : Projet J2EE + ZK Framework + ActiveObjects (persistance)
Le projet est destiné a être utilisé par un nombre important de personne en même temps et le diagramme UML est conséquent et assez complexe.

J'ai créé un "point d'entré" unique pour l'application (un singleton nommé Application). L'idée est d'accéder à partir de celui-ci aux Factories, Controllers et diverses constantes...

Ma question concerne l'EntityManager.
Actuellement, Application créé un EntityManager unique, partagé sur toute l'application.
Est-ce que c'est la bonne façon de faire ?
Peut-il y avoir des utilisations concurentes (et dans ce cas dois-je synchroniser son utilisation ou créer un EntityManager par DAO/Controller ?).

Malheureusement je n'ai pas assez de connaissance sur l'environnement J2EE/Tomcat. Je ne demande qu'à apprendre !

Comment le géreriez-vous ?

Merci d'avance pour votre réponse.

Bonjour,

pour répondre sur une partie de ton projet, je dirais que ce n'est très certainement pas une bonne idée de partager le même EntityManager (em) dans toute ton application.
Tu pourrais par contre, faire/créer un EntitManagerFactory (emf) unique et que tu utiliseras à chaque fois pour instancier un "em" à chaque fois que tu en auras besoin !

Autrement dit,
- tu fais un singleton qui retourne le même EntityManagerFactory (emf)
- tu fais une fabrique qui te retourne une EntityManager (em) à partir de l'emf.

Mais ne pas faire un singleton pour "em"

Cordialement

C'est bien ce que je pensais. Effectivement, j'ai une Factory pour l'EntityManager.

J'ai fais un test sur le partage des instances (entre clients), et j'ai des concurrents exceptions
quand j'ai le même EM. Je pourrais mettre des synchronized sur les utilisations de l'EM,
mais ce serait certainement plus lent que d'en créer quand j'en ai besoin !

Et que penses-tu de créer un EM par client en gardant celui-ci en session ?

Merci encore !

Bah, ça dépend de comment est architecturé ton projet et si entre autre un client (pendant une session) peut exécuter ou non un job en parallèle avec le même entitymanager.
Autrement dit, est ce que ton client risque de faire 2 jobs en parallèle avec le même 'em' :roll:
Si le client ne fait pas des jobs multithreadés avec le même "em", pourquoi pas.
Sinon, si le client lances des threads, alors je dirais que c'est pas une très bonne idée.

Ah mince, ZK est multithreadé puisqu'il lance (pour un même client) des requêtes AJAX.
Ces requêtes feront donc appel au même EM.

En clair, il faut soit désactiver le multithreadé sur ZK, soit créer un EM à chaque fois
qu'on effectue une opération sur la BDD et le fermer ensuite...
Ça fait du code en plus tout çà. Je pourrais faire un contrôleur abstrait qui ouvre une connexion,
appel la méthode de l'implémentation puis ferme la connexion...

Ou alors je met des synchronized sur l'EM qui est en session (et donc unique par client)...

(1) Je ne te conseille pas de faire des "synchronized" sur tes "em", ça alourdit ton code, rend difficile la maintenance etc etc ...
(2) Crées une nouvelle "em" pour chaque traitement puis ferme la. (je pense que c'est plus simple et efficace)
(3) JPA a une API qui te permet de gérer les traitements concurrentiels ... (raison de plus pour ne pas utiliser 'synchronized')

hum, pour ce que je vois de ActiveObject, c'est tout sauf du JPA.

moi je me débrouillerait pour n'avoir qu'une seule instance de EntityManager dans mon application, que ce soit via un object static, ou injection de dépendance.
visiblement d'apres la doc, c'est comme ca que ca doit être utilisé


tu l'initialises une bonne fois pour toute, et ensuite tu l'utilises partout

Pour ActiveObjects, je pense qu'il faut effectivement une seule instance.

Par contre, si on prend JPA, là le problème se pose et il serait intéressant de se poser la question également.

Mais du coup, vos avis sont contradictoires, il en faudrait un troisième au moins :lol:

pour JPA aussi : un em par database. c'est le pattern central de cette api

pas mal activeObject : je connaissais pas. je cherche une api dans ce genre
j'avais vu passer http://code.google.com/p/activejdbc/ de mon coté

J'avais vu activeJDBC aussi, mais je préfère avoir les méthodes déclarées que d'appeler via des chaînes.

Moi personnellement, je ne suis pas très convaincu que ce soit la meilleure idée que d'utiliser un 'em' en statique dans toute l'application. :roll:

en statique ou injecté ( ou via un singleton ou ce qu'on veut) l'essentiel étant de n'avoir qu'une seule instance.

sinon, dans le cas de activeObject, d’après la doc, tu vas créer une (voir des connexions) a la base a chaque création d'un nouvel objet


ca a l'air vraiment pas mal ce activeObject. je me le note dans mes tablettes :ccool:

Héhé, oui j'ai fais un peu de veille techno. D'ailleurs je t'invite a le tester rapidement
sur quelques entités de base avec des liens 1<->n et/ou n<->n et me dire si tu as des comportements... bizzares :)

De mon côté, j'ai des incompréhensions sur les @OneToMany, tu me diras si tu y arrives comme dans la doc ?

Pour JPA sinon, tu ne mettrai aucun vérrou ? Le singleton, c'est ce que j'avais fait,
mais j'ai eu quelques bugs, mais peut-être était-ce du à Zk uniquement...

Moi, je n'ai pas le courage de m'engager sur un gros projet en utilisant ce framework ActiveObject .. JPA/Hibernate/TopLink/EclipseLink semblent non seulement dominer, mais suffir à la quasi totalité des besoins tout en restant dans une grande communauté disponible et réactive et bien connue.

en JEE6, l'entity manager est fait pour être injecté directment une fois instancié par le conteneur donc il en faut un seul. Ses méthodes sont thread safe, donc aucun soucis.
De ce que j'en comprends, c'est la meme approche pour activeObject

Apres on peut toujours l’utiliser a traver des Dao, services ou même un EntityManagerWrapper, mais le résultat est le même.

Citation:

---

Envoyé par paissad

Moi, je n'ai pas le courage de m'engager sur un gros projet en utilisant ce framework ActiveObject .. JPA/Hibernate/TopLink/EclipseLink semblent non seulement dominer, mais suffir à la quasi totalité des besoins tout en restant dans une grande communauté disponible et réactive et bien connue.

---

J'avoue que sur certains projet qui ont peu d'interactions base de données (genre quelques tables et c'est tout) : je trouve que JPA et toutes ses implémentations sont souvent trop lourds pour peu de choses. (grosse empreinte mémoire, caches complexes etc...) et revenir a une approche plus simple est plus efficace.

par contre, si je devais faire une application tres orienté edition de base, je continuerai avec hibernate

Quand j'avais lu la documentation sur JPA en effet, j'avais bien compris qu'il n'en fallait qu'un seul, et j'avais donc fais un singleton Application (static) qui créait un entity manager qu'il distribuait. Mais, comme dirait Maître Yoga, nombreuses des erreurs j'ai eu.

Bien sûr, la plupart des erreurs sont applicatives mais il y a un problème qui n'est pas souvent évoqué avec JPA. JPA créé une sorte de nuage des objets (par rapport aux données en BDD) ou proxy. Imaginons un bug dans une suppression en cascade (un oubli de programmation donc), ce qui m'est arrivé ! Et bien on se retrouve avec des NullPointerExceptions car l'application a des objets (du nuage) qui n'existent plus en BDD. Ou alors, je n'ai pas compris le principe, et c'est fort probable ! Dans ce cas, peut-être pourriez-vous m'éclairer ?

Je vois que l'avantage d'une API où l'on fait "à chaque fois" des requêtes (pas de cache, pas de nuage), c'est qu'on est sûr d'avoir ce qu'il y a à l'instant T en BDD, càd soit rien, soit l'objet. Et quand le nombre de requêtes est raisonnable, les performances ne sont pas si terribles !

Concernant mes problèmes, j'ai regardé une application un peu plus ancienne en interne (J2EE + ZK), qui n'a jamais eu (jusqu'à aujourd'hui) de ConcurrentModificationException (et autres dans le genre). Et il s'avère que cette application créé un EntityManager par session (et les détruit à la destruction de la session et/ou au logout).

J'ai donc modifié légèrement mon architecture dans ce sens. Demain l'application sera soumise à un test pour la stresser avec plusieurs utilisateurs. Je ferai un retour et une petite conclusion (pour mon cas précis).

En fait, ma question concernait ZK+ActiveObjects. Mais ce qui m'intéressait, c'était la bonne manière de m'y prendre avec l'EM (que ce soit avec AO ou JPA). Cependant en réalité, mon projet à problèmes tourne avec ZK+JPA, donc c'est bien d'en avoir parlé ! (je ne compte pas encore passer sur AO) :D

Je viens juste clore la discussion mais avant... quelques conseils pour tous ceux qui souhaiteraient utiliser ZK + JPA. Ce sont des conseils à prendre avec précaution car ils viennent de ma propre expérience avec ZK/JPA et des difficultés que j'ai rencontrés. Mais enfin, depuis mes dernières modifications, mes applications tournent beaucoup mieux ! (plus de plantage, plus de bugs "modification concurrente").

Conseil numéro 1 : Utiliser au maximum les CASCADE avec JPA (dit autrement, éviter les parcours de listes et suppressions manuelles).

Conseil numéro 2 : Utiliser un EntityManager par session. Vous pouvez implémenter un session listener qui ferme l'EntityManager à la suppression de la session. J'ai l'impression, peut être fausse, qu'un bug éventuel ou une erreur avec L'entityManager est ainsi "délimitée" (les répercutions éventuelles sur d'autres utilisateurs sont évitées ?).

Conseil numéro 3 : Pour les opérations de suppression/mise à jour via des liaisons complexes, préférer des requêtes SQL simples via l'EntityManager aux parcours de listes ! Imaginez deux entités "liaison" : ProjectUser et PerimeterUser. Vous voulez supprimer un utilisateur ? Pourquoi faire plusieurs parcours (objet) via le projet, puis les périmètre etc... Au lieu de faire un DELETE de l'utilisateur directement dans les 2 tables puis dans la table User... (et ne pas oublier le resfresh sur le projet !)

Conseil numéro 4 : Utilisez des interfaces ! Surtout quand, comme moi, vous souhaitez en cours de route modifier des implémentations pour trouver pourquoi votre application plante ! Et du coup, centraliser l'accès de vos DAO et contrôleurs (et éventuellement factories etc...) au sein d'un singleton (point d'entré de l'application), vous pouvez même y mettre toutes vos constantes.

Voilà j'ai fini. A prendre comme bon vous semble !

La discussion est close, je viens un peu tard, désolé.

J'ai de grosse réserve sur la mise en session d'un entityManager. En effet, il représente +/- la connexion avec la DB (donc une instance de java.sql.Connection en quelque sorte).
Utiliser une seule et même connexion par session risque d'augmenter considérablement le nombre de connexions actives à la DB, et pour peu que les licences soient payantes, on voit tout de suite le problème. Il ne faut pas perdre de vue non plus que la session à une durée d'inactivité qui peut être longue alors que le client à déjà fermé son navigateur.
Qui plus est, ça va à l'encontre de l'usage des pools de connexions.

Pour moi, on devrait avoir un entityManager par request/response, ni plus, ni moins, et idéalement jusqu'à la fin de la phase response (pour éviter les problèmes éventuels de lazy loading).

Le problème est résolu, mais on peut quand même encore discuter, c'est intéressant, non ?!

Cela fait quelque jours que l'application tourne sur ce modèle (1 EM/session), et la mémoire est stable, pas plus haute qu'avant.
Autrement dit, la fermeture et la destruction des EM est assez rapide (la durée de session n'est pas assez longue pour avoir des problème de place mémoire). L'action logout aussi appelle la destruction de la session et donc la fermeture de l'EM.

Mon architecture est basée sur le fait qu'il n'y ait qu'un seul EM (avant c'était 1 EM pour tous les utilisateurs, maintenant c'est 1 EM par utilisateur).
Celui-ci est passé en paramètre à mes DAO, qui eux-même héritent d'un DAO générique.

Ce que tu me suggères c'est de créer à chaque fois un EM, d'ouvrir la transaction, de faire ma requête, fermer la transaction et fermer l'EM à chaque requête ?
Si c'est le cas, je dois changer (un peu) mon architecture. J'essairai bien ta suggestion si jamais je suis confronté dans les prochains jours à une exception lié à l'EM ;) Mais tant que çà roule...