[Hibernate] gestion du cache, best practices et sessions

gestion du cache, best practices et sessions [Hibernate] - Java - Programmation

Marsh Posté le 26-06-2008 à 11:06:17    

Bonjour tout le monde,
 
Je suis actuellement entrain de réaliser la partie traitement de données d'une application web. Pour cela, j'ai décidé d'utiliser le duo Hibernate et PostGres. J'ai réaliser tout le traitement de donnée en utilisant les méthodes save, update et les criterions qui semblaient adaptés dans le cadre de requêtes simples. J'ai testé les performances de mes traitements à l'aide de tests unitaires en localhost (plus de 1000 fois chaque requête pour connaitre le temps de réponse moyen, sans vider le cache). Certaines requêtes mettent presque 1 seconde à l'exécution. J'ai chercher sur le net, j'ai remarqué que l'utilisation des deux caches de Hibernates (requête et secondaire) et la bonne gestion des sessions pouvaient aider à diminuer le temps d'exécution des requêtes récurrentes. Le seul problème, c'est que je n'arrive pas à trouver de tutorial clair expliquant l'utilisation de tout ça.
 
Dés lors, j'aimerais des conseils sur les domaines suivants:
- la gestion des session afin d'avoir une gestion des données multi-threader optimale
- la gestion du cache de premier niveau de hibernate
- la gestion du cache de second niveau de hibernate
- les best practices sur Hibernate
 
Voici les différentes sources qui vous permettrons de comprendre un peu comment tout cela marche
 
Le fichier de config de hibernate :

Code :
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <!DOCTYPE hibernate-configuration
  3.     PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
  4.     "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
  6. <hibernate-configuration>
  7. <session-factory >
  9.  <!-- local connection properties -->
  10.  <property name="hibernate.connection.url">jdbc:postgresql://localhost/Report</property>
  11.  <property name="hibernate.connection.driver_class">org.postgresql.Driver</property>
  12.  <property name="hibernate.connection.username">mathieu</property>
  13.  <property name="hibernate.connection.password">mathieu</property>
  14.  <!-- property name="hibernate.connection.pool_size"></property -->
  16.  <!-- EhCache -->
  17.  <property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
  18.  <property name="hibernate.cache.use_query_cache">true</property>
  19.  <property name="hibernate.cache.use_second_level_cache">true</property>
  20.  <property name="hibernate.cache.use_structured_cache">true</property>
  22.  <!-- dialect for PostgreSQL -->
  23.         <property name="dialect">org.hibernate.dialect.PostgreSQLDialect</property>
  24.         <property name="hibernate.show_sql">false</property>
  25.         <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
  27.  <!-- mapping for Table -->
  28.  <mapping resource="com/modele/donnees/Message.hbm.xml"/>
  29. </session-factory>
  30. </hibernate-configuration>


le fichier de mapping de Message :

Code :
  1. <?xml version="1.0"?>
  2. <!DOCTYPE hibernate-mapping PUBLIC
  3. "-//Hibernate/Hibernate Mapping DTD//EN"
  4. "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >
  6. <hibernate-mapping package="com.modele.donnees">
  7. <class
  8.  name="Message"
  9.  table="message"
  10. >
  11.  <meta attribute="sync-DAO">false</meta>
  12.  <id
  13.   name="Id"
  14.   type="integer"
  15.   column="message_id"
  16.  >
  17.   <generator class="sequence"/>
  18.  </id>
  20.  <property
  21.   name="TypeMessage"
  22.   column="type_message"
  23.   type="string"
  24.   not-null="false"
  25.   length="15"
  26.  />
  27.  <property
  28.   name="Dateecriture"
  29.   column="dateecriture"
  30.   type="date"
  31.   not-null="false"
  32.   length="13"
  33.  />
  34.  <property
  35.   name="Masquer"
  36.   column="masquer"
  37.   type="boolean"
  38.   not-null="false"
  39.   length="1"
  40.  />
  41.  <property
  42.   name="ContenuMessage"
  43.   column="contenu_message"
  44.   type="string"
  45.   not-null="false"
  46.  />
  47.  <many-to-one
  48.   name="Membre"
  49.   column="membre_id"
  50.   class="Membre"
  51.   not-null="true"
  52.  >
  53.  </many-to-one>
  56.  <set name="LienMembreCompteRendus" inverse="true">
  57.   <key column="message_id"/>
  58.   <one-to-many class="LienMembreCompteRendu"/>
  59.  </set>
  62. </class>
  63. </hibernate-mapping>


la classe de gestion des sessions : (j'avouais que je l'ai rouver sur le net et que je l'ai pas encore vraiment retravailler)

Code :
  1. package com.dao.connexion;
  3. import org.hibernate.HibernateException;
  4. import org.hibernate.SessionFactory;
  5. import org.hibernate.cfg.Configuration;
  6. import org.hibernate.classic.Session;
  8. public class connexion
  9. {
  11. private static final SessionFactory sessionFactory;
  13. static
  14. {
  15.  try
  16.  {
  17.   sessionFactory = new Configuration().configure().buildSessionFactory();
  18.  }
  19.  catch (HibernateException ex)
  20.  {
  21.   throw new RuntimeException("Exception building SessionFactory: "+ ex.getMessage(), ex);
  22.  }
  23. }
  25. public static final ThreadLocal session = new ThreadLocal();
  27. public static Session currentSession() throws HibernateException
  28. {
  29.  Session s = (Session) session.get();
  30.  // Open a new Session, if this Thread has none yet  
  31.  if (s == null)
  32.  {
  33.   s = sessionFactory.openSession();
  34.   session.set(s);
  35.  }
  36.  return s;
  37. }
  39. public static void closeSession() throws HibernateException
  40. {
  41.  Session s = (Session) session.get();
  42.  session.set(null);
  43.  if (s != null)
  44.   s.close();
  45. }
  46. }


le code permettant de creer un message :

Code :
  1. Session session = connexion.currentSession();
  2. Transaction transaction = session.beginTransaction();
  3. session.save(nouveauMessage);
  4. for (Iterator<LienMembreCompteRendu> iterator = lien.iterator(); iterator.hasNext();)
  5. session.save((LienMembreCompteRendu) iterator.next());
  6. transaction.commit();
  7. connexion.closeSession();


(Je crois que c'est pas terrible ce que je fais la, le close connexion  :sweat: )
 
et le fichier de recherche de message :

Code :
  1. Session session = connexion.currentSession();
  2. if (identifiant != "" )
  3. {
  4. try
  5. {
  6.  listMessage.add((Message)session.createCriteria(Message.class)
  7.        .add( Restrictions.eq("Id",Integer.parseInt(identifiant))).uniqueResult());
  8. }
  9. catch(ClassCastException ex){new RapportErreur(ex,classe);}
  10. }
  11. else
  12. listMessage = session.createCriteria(Message.class)
  13.     .list();


 
Voila. Pouvez vous me donner vos commentaires et me donner des petits conseils? Merci


---------------
En informatique, il n'y a pa de solution, que des problèmes :)
Reply

Marsh Posté le 26-06-2008 à 11:06:17   

Reply

Marsh Posté le 26-06-2008 à 14:30:53    

Je sais que c'est un peu long à lire, alors un peu de courage.  ;)
 
Si vous avez des liens ou autres vous gênez pas

Reply

Marsh Posté le 27-06-2008 à 15:34:01    

je connait plus la partie JPA de hibernate mais quand même une remarque:
On peux définir des "fetch plan" pour la lecture de donnée et des "cascade" pour le persist:
Du coup pas besoin de sauver LienMembreCompteRendu, le save de "message" suffit. (ca c'est pour le cascade, le fetch c'est pour la lecture et ne pas avoir des lazyException
 
Pour ce qui est de la fermeture de la session à chaque méthode c'est pas le mieux non plus il me semble.  
Voir le design pattern "open session in view" pour une solution simple (mais qui à des effets de bords)
 
Les annotations springs peuvent faire beaucoup. Pour une nouvelle application, je conseillerai de commencer avec JPA (et l'implémetation d'hibernate) plutot que du pur hibernate.

Message cité 1 fois
Reply

Marsh Posté le 27-06-2008 à 16:12:17    

tempo14 a écrit :

je connait plus la partie JPA de hibernate mais quand même une remarque:
On peux définir des "fetch plan" pour la lecture de donnée et des "cascade" pour le persist:
Du coup pas besoin de sauver LienMembreCompteRendu, le save de "message" suffit. (ca c'est pour le cascade, le fetch c'est pour la lecture et ne pas avoir des lazyException
 
Pour ce qui est de la fermeture de la session à chaque méthode c'est pas le mieux non plus il me semble.  
Voir le design pattern "open session in view" pour une solution simple (mais qui à des effets de bords)
 
Les annotations springs peuvent faire beaucoup. Pour une nouvelle application, je conseillerai de commencer avec JPA (et l'implémetation d'hibernate) plutot que du pur hibernate.


 
Merci pour les informations, j'étais justement entrain de regarder les fetch plan et plus particulièrement le lazy loading afin d'optimiser le chargement car j'ai l'impression qu'hybernate à une stratégie agressive de base. Je me suis également penché sur le cache, et à ce niveau la j'ai un problème curieux. Il met 2 fois plus de temps avec le cache que sans (cache de second niveau), je pense que j'ai pas bien paramétré tout ça encore. Je vais regardé le design pattern que tu me conseil aussi.
 
PS: pour ceux qui cherchent des informations sur le cache de second niveau d'hibernate allez voir ce site
http://www.devx.com/dbzone/Article/29685/0/page/1
Il est pas mal, en plus y a un exemple.

Reply

Marsh Posté le 27-06-2008 à 16:15:41    

par défaut (au moins en JPA) hibernate fait du lazy loading pour les type complexe, pas pour les String, Double et autre Integer

Message cité 1 fois
Message édité par tempo14 le 27-06-2008 à 16:17:12
Reply

Marsh Posté le 27-06-2008 à 16:19:01    

tempo14 a écrit :

par défaut (au moins en JPA) hibernate fait du lazy loading


Okay, je comprend pas d'où viens c'est temps de recherche excessif alors. Presque 1 seconde pour charger certaines données.

Reply

Marsh Posté le 27-06-2008 à 16:25:07    

par contre dans le lien que tu donnes, on voit que le cache de premier niveau est associé à la session. C'est pas une bonne idée de l'ouvrir et la fermer dans chaque méthode. Pour ce qui est du problème de performance, un "showsql=true" donne généralement de bonne indications

Message cité 1 fois
Reply

Marsh Posté le 27-06-2008 à 16:45:46    

tempo14 a écrit :

par contre dans le lien que tu donnes, on voit que le cache de premier niveau est associé à la session. C'est pas une bonne idée de l'ouvrir et la fermer dans chaque méthode. Pour ce qui est du problème de performance, un "showsql=true" donne généralement de bonne indications

 

Le cache de premier niveau n'est pas propre a une session? J'avais cru comprendre que le cache de premier niveau (requête) l'était et que le second niveau était commun à tous?

 

Au fait, je suis entrain de regarder la cascade sur le lien suivant (chapitre 21.3)
http://www.hibernate.org/hib_docs/ [...] child.html
Je comprend pas j'ai pas commit dans la base on diré? pourtant tout correspond aux explications et j'ai même testé avec une transaction?


Message édité par iviath le 27-06-2008 à 16:49:59
Reply

Marsh Posté le 27-06-2008 à 17:11:36    

Citation :

Le cache de premier niveau n'est pas propre a une session?


oui c'est ca, pourquoi? je ne dis pas l'inverse?
 

Citation :

Je comprend pas j'ai pas commit dans la base on diré? pourtant tout correspond aux explications et j'ai même testé avec une transaction?


Je pense que le commit au niveau de la db ne se fait pas nécessairement au "transaction.commit();" mais plutôt au "session.flush();" (à valider)

Message cité 1 fois
Reply

Marsh Posté le 27-06-2008 à 17:25:20    

tempo14 a écrit :

Citation :

Le cache de premier niveau n'est pas propre a une session?


oui c'est ca, pourquoi? je ne dis pas l'inverse?


 
Ben tu avais l'air de dire que le cache de premier niveau n'est pas propre à une session et j'ai cru comprendre que cache session avait son propre cache de requête.
 

tempo14 a écrit :


Citation :

Je comprend pas j'ai pas commit dans la base on diré? pourtant tout correspond aux explications et j'ai même testé avec une transaction?


Je pense que le commit au niveau de la db ne se fait pas nécessairement au "transaction.commit();" mais plutôt au "session.flush();" (à valider)


 

Code :
  1. Session session = connexion.currentSession();
  2. Base base = (Base)session.load(Base.class, id));
  3. base.addToDepartements(nouveauDepartement);
  4. session.flush();
  5. connexion.closeSession();


 
Déjà au debuger il me retourne pas une classe de type Base on dirait, et même quand la base est bonne il sauvegarde pas.

Reply

Marsh Posté le 27-06-2008 à 17:25:20   

Reply

Marsh Posté le 01-07-2008 à 15:20:12    

Le cache de requête

 

Pour tous ceux que ça intéresse, je viens de comprendre comment marcher le cache de requête. J'en fait tout de suite profiter tout le monde. Déjà, il faut savoir qu'il existe plusieurs fournisseurs de caches différents (tableau  19.1 page http://www.hibernate.org/hib_docs/ [...] ance-cache)  , personnellement j'ai utilisé ehcache.
Le cache de requete se paramètre à plusieurs niveaux:
- dans le fichier de config de hibernate (ici le hibernate.cfg.xml)
- dans un fichier ehcache.xml dans le classpath

 

dans le fichier de config d'hibernate il faut activer le fournisseur de cache et définir les classes l'implémentant:

Code :
  1. <property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property> // permet de sélectionner le type de fournisseur
  2. <property name="hibernate.cache.use_query_cache">true</property> //permet d activer le cache de requete
  3. <property name="hibernate.cache.use_second_level_cache">false</property> //permet de désactiver le cache de second niveau (optionnel)
  4. <property name="hibernate.cache.use_structured_cache">true</property>
  5. <property name="hibernate.cache.use_minimal_puts">true</property> // permet d'optimiser l'utilisation du cache en clusters
 

ensuite regler le fichier ehcache.xml

 
Code :
  1. <ehcache>
  3. <defaultCache  // cache par defaut
  4.  maxElementsInMemory="10000" // nombre d'objet en cache
  5.  eternal="false" // persistance aprés arret
  6.  overflowToDisk="false" // ecriture sur le disque en cas de depassement mémoire
  7.  timeToIdleSeconds="120" // temps de persistance des objets
  8.  timeToLiveSeconds="120" // temps de vie des objets
  9.  diskPersistent="true" // ecriture sur le disque
  10.  diskExpiryThreadIntervalSeconds="120" // temps d expiration des threads
  11. />
  13. <cache
  14.  name="net.sf.hibernate.cache.StandardQueryCache" // cache de requete
  15.  maxElementsInMemory="10"
  16.  eternal="false"
  17.  timeToLiveSeconds="120"
  18.  overflowToDisk="false"
  19.  />
  20. </ehcache>


Message édité par iviath le 02-07-2008 à 11:36:57
Reply

Marsh Posté le 02-07-2008 à 11:43:04    

best practices

 

Voici l'ensmble des best practices que j'ai trouver sur le net, si vous avez des suggestion, ne vous gênez pas.

 

- la recherche d'un objet dans une table se fait toujours à l'aide d'un load ou get. Ceci permet de rechercher dan un premier temps dans le cache avant de rechercher dans la table. Il existe une différence fondamentale entre le load et le get. En cas d'objet non trouver dans la table le get retourne un objet null et le load soulève une exception.
exemple:

Code :
  1. Object objet = session.load(MaTable.class,MonIdentifiant);


- Les criteria / criterions sont à utiliser de préférence pour les requêtes simples et le HQL dans le cadre de requête plus complexe.


Message édité par iviath le 02-07-2008 à 11:43:20
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed