IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JPA Java Discussion :

@OneToMany unidirectionel: Trop de requetes SQL générées


Sujet :

JPA Java

  1. #1
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut @OneToMany unidirectionel: Trop de requetes SQL générées
    J'ai un EJB pour un object Bookmark qui contient une collection de BookmarkEntry (un autre EJB)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    @OneToMany(cascade={CascadeType.PERSIST, CascadeType.MERGE}, fetch=FetchType.LAZY) 
    public Collection<BookmarkEntry> getEntries() { 
    return _entries; 
    }
    Rien n'est défini au niveau de l'EJB BookmarkEntry.

    Lors de l'insert d'un BookmarkEntry dans la collection trop de requetes SQL sont générées !!!

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
            EntityManagerFactory emf = 
                Persistence.createEntityManagerFactory(JPA_PROVIDER);
            EntityManager em = emf.createEntityManager();
            em.getTransaction().begin();
            Bookmark bookmark = em.getReference(Bookmark.class, 1);
     
            BookmarkEntry entry = new BookmarkEntry();
            entry.setUrl("URL4");
            bookmark.getEntries().add(entry);
            em.merge(bookmark);
            em.getTransaction().commit();


    Hibernate: select bookmark0_.id as id8_0_, bookmark0_.location as location8_0_, bookmark0_.name as name8_0_ from Bookmark bookmark0_ where bookmark0_.id=?
    Hibernate: select entries0_.Bookmark_id as Bookmark1_1_, entries0_.entries_id as entries2_1_, bookmarken1_.id as id10_0_, bookmarken1_.description as descript2_10_0_, bookmarken1_.url as url10_0_ from Bookmark_BookmarkEntry entries0_ left outer join BookmarkEntry bookmarken1_ on entries0_.entries_id=bookmarken1_.id where entries0_.Bookmark_id=?
    Hibernate: insert into BookmarkEntry (description, url) values (?, ?)
    Hibernate: delete from Bookmark_BookmarkEntry where Bookmark_id=?
    Hibernate: insert into Bookmark_BookmarkEntry (Bookmark_id, entries_id) values (?, ?)
    Hibernate: insert into Bookmark_BookmarkEntry (Bookmark_id, entries_id) values (?, ?)
    Hibernate: insert into Bookmark_BookmarkEntry (Bookmark_id, entries_id) values (?, ?)
    Hibernate: insert into Bookmark_BookmarkEntry (Bookmark_id, entries_id) values (?, ?)
    Hibernate: insert into Bookmark_BookmarkEntry (Bookmark_id, entries_id) values (?, ?)

  2. #2
    Membre éclairé Avatar de TheEwook
    Inscrit en
    Novembre 2004
    Messages
    44
    Détails du profil
    Informations personnelles :
    Âge : 43

    Informations forums :
    Inscription : Novembre 2004
    Messages : 44
    Par défaut
    Salut,

    A mon avis un mauvais paramétrage de ton fichier hbm correspondant?
    Tu peux nous le montrer ton fichier hbm ?

    Merci

  3. #3
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut EJB3 with hibernate sans fichier hbm
    J'utilise Hibernate comme provider EJB3. Je ne défini qu'un fichier persistence.xml et des annotations dans mes Entity.

    Quelle est la plus value d'ajouter en plus ce fichier hbm ??? pour moi ,il n'y en a pas besoin !!!

  4. #4
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par fvisticot Voir le message
    J'utilise Hibernate comme provider EJB3. Je ne défini qu'un fichier persistence.xml et des annotations dans mes Entity.

    Quelle est la plus value d'ajouter en plus ce fichier hbm ??? pour moi ,il n'y en a pas besoin !!!
    la relation OneToMany unidirectionnelle est un classique des discussions des forums Hibernate, et pour résumer : les concepteurs d'Hibernate déconseillent toujours cette solution quand elle est utilisée sans une table de jointure (votre cas)…
    et préfèrent souvent la solution bidirectionnelle…

    "7.2.3. one to many
    A unidirectional one-to-many association on a foreign key is a very unusual case, and is not really recommended. "

    dans votre cas, passez au bidirectionnel et ajouter un "mappedBy" du côté @OneToMany
    et du côté @ManyToOne ne pas oublier de mettre "nullable=false" sur la foreign key…

    (tout est dans la doc Hibernate… mais avec des exemples .hbm pas d'exemple avec annotation…)

  5. #5
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Merci pour la réponse.
    Mais j'ai quand meme un peu de mal à choisir cette solution car si j'ai bien compris, le coté manyToOne est le "master" de la relation.
    Donc dans mon cas, il s'agit du bookMarkEntry qui est le maitre de la relation.

    Donc pour sauver les éléments que contient mon bookmark (les élements ont été ajoutés par bookmark.getEntries().add(bookmarkEntry)), nous sommes obligé de persister chaque element du bookmark:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    for (BookmarkEntry entry: bookmark.getEntries()) {
      entry.setBookmark(bookmark)
      em.persist(entry)
    }
    Il aurait été plus simple que le bookmark soit le maitre de la relation et faire uniquement un
    Avez vous une solution à ce pb ?

  6. #6
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par fvisticot Voir le message
    Merci pour la réponse.
    Mais j'ai quand meme un peu de mal à choisir cette solution car si j'ai bien compris, le coté manyToOne est le "master" de la relation.


    le "master" ?

  7. #7
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    Bonjour,
    Tu as deux méthode pour le persist:
    - Soit tu déclares un cascade sur l'insert, ainsi, un simple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    bookmark.setEntry(entry);
    entry.getBookmarks().add(bookmark)
    suffit à persister le bookmark. (Mais j'aime pas trop cete approche là).
    - Soit tu y vas à la dure, mais au fur et à mesure:
    A chaque fois que tu as un bookmarke à persister, tu fais:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    bookmark.setEntry(entry);
    em.persist(bookmark);
    em.persist(entry);

  8. #8
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Citation Envoyé par JeitEmgie Voir le message
    le "master" ?
    Pour moi le "master" est le coté de la relation qui est utilisé pour persister.

    Dans mon cas:
    BookmarkEntry a une relation @manyToOne avec Bookmark.
    De l'autre coté Bookmark a une relation @OneToMany avec un mappedBy sur "bookmark". et contient un tableau de BookmarkEntrie

    Quand on veut persister un bookmark qui contient un tableau de BookmarkEntry, vu que le coté "master" est le BookmarkEntry il faut persister chaque BookmarkEntry contenus dans le tableau avec:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    bookmarkEntry.setBookmark(bookmark)
    bookmark.getBookmarkEntries().add(bookmarkEntry);
    em.persist(bookmarkEntry);
    em.persist(bookmark);
    J'aurai voulu éviter la ligne em.persist(bookmarkEntry) et seulement avoir:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    bookmark.getBookmarkEntries().add(bookmarkEntry);
    em.persist(bookmark);
    Dans ce cas, le bookmark est persisté mais les bookmarkEntry ne le sont pas.

    En espérant être clair.

  9. #9
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Merci pour ta réponse mais cela n'est pas clair pour moi.
    Pour résumer j'ai un object Bookmark qui contient un tableau d'object BookmarkEntry.

    Je veux persister en une seule commande "persist" mon Bookmark et toutes les entries contenues dans son tableau.
    em.persist(bookmark);

    avec les relations definies avec ManyToOne et OneToMany, vu que le mappedBy est du coté du BookmarkEntry alors le fait de persister le bookmark ne va pas persister les bookmarkEntries contenues dans le tableau du bookmark;

    Il faut donc persister chaque BookmarkEntry avant de persister le bookmark.

    Je ne trouve pas ca très pratique car dans le cas ou j'ai un object Bookmark avec 10 elements BookmarkEntry, je suis obligé de boucler sur les BookmarkEntry est de faire des em.persist(bookmarkEntry).

    Peut etre n'ais je rien compris !!!


    Question: Qu'appelles tu "Faire un cascade sur l'insert" ? Comment le spécifies tu avec des annotations ?

  10. #10
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    Non, c'est presque ça, mais t'as un problème d'ordre + problème de refresh:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    em.persist(bookmark);
    bookmark = em.merge(bookmark);//<-important ça
     
    foreach(BookmarkEntry){
      bookmarkEntry.setBookmark(bookmark);
      em.persist(bookmarkEntry);
      bookmarkEntry = em.merge(bookmarkEntry);
      bookmark.getBookmarkEntries().add(bookmarkEntry);
    }
     
    em.persist(bookmark);
    Le but étant ceci: Ne jamais faire pointer un objet persisté vers un autre non persisté, d'où les contraintes sur l'ordre mais aussi sur l'utilisation de merge pour récupérer l'instance persistée.

  11. #11
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par djo.mos Voir le message
    Non, c'est presque ça, mais t'as un problème d'ordre + problème de refresh:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    em.persist(bookmark);
    bookmark = em.merge(bookmark);//<-important ça
     
    foreach(BookmarkEntry){
      bookmarkEntry.setBookmark(bookmark);
      em.persist(bookmarkEntry);
      bookmarkEntry = em.merge(bookmarkEntry);
      bookmark.getBookmarkEntries().add(bookmarkEntry);
    }
     
    em.persist(bookmark);
    Le but étant ceci: Ne jamais faire pointer un objet persisté vers un autre non persisté, d'où les contraintes sur l'ordre mais aussi sur l'utilisation de merge pour récupérer l'instance persistée.
    persist + merge du même objet dans la même transaction ???????

    Un objet a 3 états possibles relativement à la session :

    transient, persistent, detached

    new crée un "transient"

    persist, save, saveOrUpdate font passer de "transient" à "persistent"

    merge, update, saveOrUpdate, lock font passer de "detached" à "persistent"

    delete fait passer de "persistent" à "transient"

    evict, close, clear font passer de "persistent" à "detached"

    get, load, find, iterate, etc. créent un objet "persistent"

    replicate passe un "persistent" directement d'une session à une autre

    merge sur un objet persistent ne fait rien du tout…
    c'est totalement inutile…

    quant au problème d'ordre : Hibernate gère très bien la persistence transitive à condition de bien déclarer les attributes "cascade" (du côté one-to-many) …

  12. #12
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    Non, le but est de récupérer l'instance persistée (attaché), vu que em.persist retourne void.

    Et pour l'ordre, oui, ça marche qui si on y va par cascade (cf un de mes posts plus haut), mais la solution que je proposais est jsutement pour le cas où y'a pas de cascading.
    Dans ce cas-ci, il faut faire très attention àl'ordre dans lequel on persste les entités, sinon, on se retrouve avec des exceptions du genre "entité persistente référence une entité non-pesistente".

  13. #13
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Je pense également qu'il ne faut pas utiliser les commandes de merge.
    Je suis dans une transaction (gérée par le container) et la transaction traite parfaitement l'ordre dans lequel les objets sont crées.
    Donc (à mon sens) et également par les tests les merges sont inutiles.

    Le pseudo code suivant est donc correct:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    foreach(BookmarkEntry){
      bookmarkEntry.setBookmark(bookmark);
      em.persist(bookmarkEntry);
      bookmark.getBookmarkEntries().add(bookmarkEntry);
    }
     
    em.persist(bookmark);
    Mais y a t'il moyen d'éviter cette boucle pour persister les BookmarkEntry et ne persister que le bookmark (qui contient les BookmarkEntries). ??
    Cette boucle est du au fait que mappedBy est du coté BookmarkEntry...
    Si on fait un mapping unidirectionnel OneToMany cote Bookmark alors
    em.persist(Bookmark) persiste également les élements du tableau (BookmarkEntries).

    Au fait, est ce que mon analyse sur le coté "master" de la relation est correcte ?

  14. #14
    Membre Expert
    Homme Profil pro
    Inscrit en
    Septembre 2006
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2006
    Messages : 2 963
    Par défaut
    Citation Envoyé par djo.mos Voir le message
    Non, le but est de récupérer l'instance persistée (attaché), vu que em.persist retourne void.
    ????????

    persist n'a pas besoin de retourner quelque chose puisque l'objet passé en paramètre est transient : c'est le même objet qui devient persisted…


    merge renvoit un objet car l'objet passé en paramètre n'est pas nécessairement celui qui sera trouvé dans la cache ou relu de la db…
    (l'objet passé en paramètre doit avoir été persisté : son id != null… et c'est sur base de cet id que merge renvoit la "bonne" version…)

  15. #15
    Expert confirmé
    Avatar de djo.mos
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    4 666
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2004
    Messages : 4 666
    Par défaut
    @JeitEmgie: Oui, je te l'accorde, mais le bout de code en question je le définis dans mes DAOs, et là, je ne peux pas faire la chose finement, vu que je n'ai pas une vision d'ensemble sur ce qui se passe.
    Je ne sais pas par exemple si on traite d'un objet transient ou détaché.

    Je code donc la chose en mode défensif, ce qui peut résulter en des actions superflues, mais je prèfère ça au lieu de polluer ma couche service avec l'API JPA

    @fvisticot: cette boucle est normalement non nécessaire si tu procèdes a fur et à mesure, c'est à dire que tu inviques le traitement pour chaque BookmarkEntry.

    Mais sinon, c'est inévitable je crois, et la solution d'une liaison uni-directionnelle est à ne pas envisager (toujours à mon avis).

  16. #16
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 28
    Par défaut
    Salut,

    Tu pourra mettre ce que tu veux comme annotations cela n'y changera presque rien.

    Le nombre de requetes est défini par le type de ta collection or tu utilisise la collection dite 'bag'. Elle est cool tu peux stocker un peu ce que tu veux sans te préocupé de l'ordre mais c'est la plus couteuse en ressources... ( les requettes... ).

    Le type 'Collection' te permet d'avoir des 'doublons' mais... Pas ta table...
    Ce qui fait que quand tu va vouloir y ajouter un element il faudra tout effacer et tout remettre...

    Bon Courage.

    PS: Tu peux réduire un peu plus son cout si tu met en place une association bidirectionnelle. Mais c'est pas un gros changement...

  17. #17
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Cool, merci pour ta réponse.
    J'ai en effet vu dans la doc hibernate qu'en mettant une Collection, cela est géré comme un bag. Ou as tu vu "quand tu va vouloir y ajouter un element il faudra tout effacer et tout remettre" c'est vrai mais je n'ai pas vu l'info..c'est quand meme important pour les perfs!!!

    Si je met un Set à la place, est ce que ce nombre de requetes va dimininuer lors d'un insert de nouvel element??

    Pour le fait de passer en bidirectionnel, je suis OK MAIS pour un max de perfs, je veux ne pas utiliser de join table entre les 2 entités...et je me heurte alors au fait que je suis obligé de persister du cote "Many"... ce qui n'est pas trés pratique quand on veux sauver facilement des tableaux d'objects...(iteration et persist sur tous les elements du tableau) ...

    Je préférerai éviter le bidirectionel car je voudrai éviter d'exposer mon attribute Bookmark dans l'entité BookmarkEntry.

  18. #18
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 28
    Par défaut Perfs
    Salut,

    Pour l'info c'est après de nombreux tests que je m'en suis rendu compte...

    Cependant, si tu met un Set tu réduit considérablement le nombre de requetes... Cela est du à la contrainte du Set (unique key) donc lorsque ta collection va être persister il y aura 3 requetes qui vont être émises.

    3 requetes? Pourquoi? Pour simple bonne raison que les 2 premieres seront des 'SELECT' ( recuperation de ton entity contenant ta collection, ensuite pour verifier que ton entity n'est pas déjà présente dans ta collection puis 2 possibilité apparaissent :

    1ere possibilité : ton entity n'est pas présente la requete sera un 'INSERT'

    2eme possibilité : ton entity est déjà présente la requete sera un 'UPDATE'

    Mais je suis d'accord avec toi sur le fait de persiter des 2 cotés c'est un peu lourd à force.

    Bon Courage.

    PS: Si tu veux vraiment t'informer sur la performance du mapping de collecitons... Si ta collection n'est pas inverse ( mapping bidirectionnel), List est plus performant car il herite du forte indexation, et après se place le Set car il a une indexation moyenne).

  19. #19
    Membre actif
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 19
    Par défaut
    Citation Envoyé par the last phoenix Voir le message
    Salut,

    Pour l'info c'est après de nombreux tests que je m'en suis rendu compte...

    Cependant, si tu met un Set tu réduit considérablement le nombre de requetes... Cela est du à la contrainte du Set (unique key) donc lorsque ta collection va être persister il y aura 3 requetes qui vont être émises.

    3 requetes? Pourquoi? Pour simple bonne raison que les 2 premieres seront des 'SELECT' ( recuperation de ton entity contenant ta collection, ensuite pour verifier que ton entity n'est pas déjà présente dans ta collection puis 2 possibilité apparaissent :

    1ere possibilité : ton entity n'est pas présente la requete sera un 'INSERT'

    2eme possibilité : ton entity est déjà présente la requete sera un 'UPDATE'

    Mais je suis d'accord avec toi sur le fait de persiter des 2 cotés c'est un peu lourd à force.

    Bon Courage.

    PS: Si tu veux vraiment t'informer sur la performance du mapping de collecitons... Si ta collection n'est pas inverse ( mapping bidirectionnel), List est plus performant car il herite du forte indexation, et après se place le Set car il a une indexation moyenne).
    Cette discussion est super interessante.
    Enfin quelqu'un qui trouve que c'est un peu lourd de persister des 2 cotés !!

    Ma conclusion:
    La solution avec un OneToMany unidirectionnel sans jointure:
    Facile à utiliser car on ne persite que le coté qui contient la collection
    MAIS
    On aura au mieux 3 requetes pour ajouter un element dans une collection (avec une set recup collection + insert).
    La solution avec un OneToMany bidirectionnel sans jointure:
    Performant car on aura une seule requete par insert
    MAIS
    Un peu lourd à coder car obligé de persister chaque élément de la collection

    Est ce pour cette raison qu'hibernate ne recommande pas l'utilisation du OneToMany non bidirectionnel ???

    Je suis très interressé par le coté persistence de données type ejb et les performances. As tu des infos la dessus (toplink, openjpa, hibernate, cocobase)
    Lorsque les perfs sont le critère primordiale, quelle solution de mapping vaut il mieux utiliser (a l'exception du SQL direct bien entendu...) ???

    Merci

  20. #20
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 28
    Par défaut Perfs
    Salut,

    Je trouve que tu as très bien résumer.

    Pour les recommandations, perso, cela dépends surtout du developpeur et rien d'autre car l'ORM est disponible pour tous et chacun l'utilisera à sa guise que ce soit pour les perfs ou pour autre chose...

    Cependant il est vrai que d'après la specification une association unidirectionnel sans table de jointure est optionnelle.

    L'une des principale regle à essayer de mettre en place est :
    " Utiliser un maximum de modularité pour un minimum de table de jointure."

    A partir de là tu gagne en perfs et en maintenabilité.

    Concernant les dernières technos il y a oracle qui a racheté toplink il faut donc s'attendre à une grosse monté de perfs Oracle/Toplink ( même si c'était déja le cas avant ).

    Mais à pour le moment hibernate reste en tête niveau perfs et utilisation.
    ( Faudra attendre Java Persistence 2.0 cette année pour bien placé la bar ).

    Mais si tu t'interresse au EJB tu à les EJB 3 qui sont remarquablement plus performant et utilisable que les anciens. Et pour un peu de lecture tu as le livre EJB 3.0 chez Dunod qui a été élaboré par les labos de SUPINFO. Je te le recommande.

    J'ai pas encor eu l'occase de me pencher sur hibernate 3.3 j'ai juste feuilleté la spécification pour voir quelques differences avec la 3.2, je te tiendrais au courant si tu veux.

    Mais pour les mappings tout dépend de tes besoins...

    Ta un exemple à me donner ?

    Merci.

Discussions similaires

  1. [MySQL] Trop grand nombre de requetes sql ?
    Par Aloam dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 16/01/2013, 14h41
  2. Réponses: 3
    Dernier message: 16/08/2011, 18h14
  3. Requete sql trop lourde
    Par sinifer dans le forum Requêtes
    Réponses: 14
    Dernier message: 11/05/2009, 00h21
  4. requete sql trop longue enregistrement en mémoire ou sur disque
    Par jyvaut75 dans le forum Requêtes et SQL.
    Réponses: 6
    Dernier message: 01/02/2008, 15h11
  5. [nHibernate] génère plusieurs requetes sql
    Par mikky dans le forum NHibernate
    Réponses: 1
    Dernier message: 08/03/2007, 09h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo