Discussion :

[saveriu]

Bonjour,

J'ai remarqué un problème lorsque je charge une liste d'entités avec une requête JPQL.
Un exemple tout simple: une entité Personne a une entité Adresse en attribut, j'ai donc une annotation @OneToOne(cascade = CascadeType.ALL, fetch=FetchType.LAZY) de Personne vers Adresse.
Cette annotation est sensée éviter le chargement de l'adresse lors d'une requête sur l'entité Personne mais étrangement, pour un findAllPersonnes() par exemple, j'ai constaté que pour n Personnes, n requêtes de sélection d'Adresse se lancent, générant de gros problèmes de performance.
J'ai contourné le problème en chargeant en une seule requête les personnes et leurs adresses grâce aux join fetch mais ce n'est pas ce que je veux.
Est-ce à cause du CascadeType.ALL?
Merci de m'aider

[saveriu]

Je viens de trouver quelque chose d'intéressant. Le LAZY LOADING ne marche que dans un conteneur J2EE.
Dans mon cas je suis dans une application cliente J2SE. C'est surement ça le problème.

[OButterlin]

Je ne pense pas, tu as peut-être un fetch join dans le cas de ta requête findAllPersonnes() auquel cas, tu by-pass l'information FetchType.LAZY

[fr1man]

Bizarre ton affaire.
Tu as le lien d'où tu tires cela ?

[DevServlet]

Vraiment bizarre ton pb, car ca remet en cause même la politique de fonctionnement EAGER ou LAZY.
peux tu nous faire voir la requete que tu faisais pour qu'il charge en même temps les adresses liées aux personnes?

[saveriu]

source: http://wiki.eclipse.org/Using_Eclips...nk_JPA_Weaving

méthode pour récupérer les personnes et leurs adresses et éviter le eager loading:

Code :

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

1
2
3
4
5
6
7
 
public List<Utilisateur> getAllUtilisateurs() {
        Query query = PersistanceUnit.getInstance().getEm().createQuery("SELECT distinct u FROM Utilisateur u join fetch u.compteVision join fetch u.adresse order by u.nom asc, u.prenom asc");
        query.setHint(QueryHints.FETCH, "join fetch u.compteVision.personne");
        query.setHint(QueryHints.FETCH, "join fetch u.compteVision.profil");
        return query.getResultList();
    }

[OButterlin]

Bon ben c'est clair, tu as bien un join fetch sur u.adresse, d'où la récupération des adresses dans ce cas.

[saveriu]

La méthode que j'ai montré permet de charger toutes les données en une seule requête.
Voici l'ancienne:

Code :

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

1
2
3
4
5
 
public List<Utilisateur> getAllUtilisateurs() {
        Query query = PersistanceUnit.getInstance().getEm().createQuery("SELECT distinct u FROM Utilisateur u order by u.nom asc, u.prenom asc");
        return query.getResultList();
    }

C'est elle qui me lance pour n utilisateurs, 5 requêtes de sélection pour charger les données en relation avec un utilisateur soit 5n requêtes!
Mais comme je l'ai dit, le problème vient du fait que le Lazy loading ne fonctionne pas hors d'un conteneur. Il y a moyen de l'activer dans un environnement J2SE mais ça m'envoie sur un autre problème que j'ai posté à propos du weaving dynamique de EclipseLink: http://www.developpez.net/forums/d88...ploiement-ejb/

[OButterlin]

Bon, dans le principe, voilà comment ça se passe.
Tout objet "attaché" peut traiter le lazy loading.
Un objet "detaché" ou "nouveau" ne le peut pas.

Il se trouve que pour les EJB, dès qu'on sort du conteneur (d'EJB), l'objet est "détaché".
Ça, c'est le cas par défaut avec JTA.
En pratique, on fait appel à une méthode d'un EJB (stateless) et à la sortie de la méthode, l'état est changé (dans les grandes lignes, ça peut être plus compliqué).
Il est possible de passer par un mode dit "extended" pour faire différemment.
Rien n'empêche de laisser la couche IHM acquérir une connexion et la libérer en fin de cycle.

La question est : utilises-tu des EJB ou des DAO (java basic) ?

[saveriu]

Dans mon cas, je suis dans une appli J2SE (le client contient l'implémentation de JPA) donc pas d'EJB, uniquement des DAO requettant la base à distance.

Tout objet "attaché" peut traiter le lazy loading.

A condition d'avoir le weaver activé.

J'ai également codé une application .ear contenant des EJB permettant de fournir les même accès aux données. Le lazy loading marche bien avec Toplink (nous sommes dans ce cas dans un conteneur de GlassfishV3), mais sous EclipseLink, le weaver me retourne une exception que je ne comprend pas.

[OButterlin]

weaver ? Connais pas... jamais utilisé... il semble que ce soit lié à Spring...

C'est bien ton application JSE qui fait l'acquisition de la connexion, non ?
Donc, tant que la connexion est ouverte, le lazy loading peut fonctionner.

Avec le lazy loading, tu as des proxy vers les entités référencées, maintenant, je ne connais pas TopLink, je n'utilise qu'Hibernate, il y a peut-être des différences...

[saveriu]

Avec le lazy loading, tu as des proxy vers les entités référencées, maintenant, je ne connais pas TopLink, je n'utilise qu'Hibernate, il y a peut-être des différences...

Oui surement, il me semble que la notion de "weaver" apparait que pour TopLink et EclipseLink...
Je ne connais pas vraiment tout le fonctionnement mais je sais qu'il est obligatoire pour le lazy loading et qu'on peut le paramétrer (statique, dynamique, etc.).
Lorsque j'aurait compris pourquoi je n'arrive pas à déployer mes EJB avec le weaver d'EclipseLink activé, je reviendrai faire un topo. Merci pour ton aide.