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

Persistance des données Java Discussion :

Problème Hibernate requête


Sujet :

Persistance des données Java

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 9
    Points : 8
    Points
    8
    Par défaut Problème Hibernate requête
    Bonjour,

    je suis en train de développer une application client serveur, en utilisant les sockets.

    Le serveur quand il reçoit un client créé un thread de traitement.
    J'utilise Hibernate pour la persistance des données, avec la classe utilitaire HibernateUtil :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    public class HibernateUtil {
     
    	private static final SessionFactory sessionFactory;
     
    	static { 
    		try {
    			// Crée la SessionFactory
    			Configuration c = new Configuration();
    			c.setProperty("hibernate.show_sql", "false");
    			sessionFactory = c.configure().buildSessionFactory();
    		} catch (HibernateException ex) {
    			throw new RuntimeException("Problème de configuration : "
    					+ ex.getMessage(), ex);
    		}
    	}
     
    	public static final ThreadLocal session = new ThreadLocal();
     
    	public static Session currentSession() throws HibernateException {
    		Session s = (Session) session.get();
    		// Ouvre une nouvelle Session, si ce Thread n'en a aucune
    		if (s == null) {
    			s = sessionFactory.openSession();
    			session.set(s);
    		}
    		return s;
    	}
     
    	public static void closeSession() throws HibernateException {
    		Session s = (Session) session.get();
    		session.set(null);
    		if (s != null)
    			s.close();
    	}
     
    	public static SessionFactory getSessionfactory() {
    		return sessionFactory;
    	}
    }
    J'ai développé un programme qui exécute un client toutes les n minutes, afin de vérifier que le serveur est toujours vivant.
    Cela fonctionne très bien, mais toutes les 1h30 (à peu près) la ligne "query.list();" ne répond plus, et bloque le thread client :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Session session = HibernateUtil.currentSession();
    Query query = session.createQuery(hql);
    query.list();
    Après le blocage, tous les autres threads clients ne peuvent plus exécuter de requête à leur tour.
    Je pré-suppose que dans une application multi-threads, cette classe n'est pas vraiment compatible, car les threads utilisent toujours la même session.
    Mais j'ai beau créé un threadLocal, une session Hibernate
    pour chaque thread, le problème persiste...

    Existe-t-il une classe utilitaire qui gère les sessions dans un contexte multi-threading ?
    Ou dans quelle direction puis-je me diriger pour avoir toujours une bonne session pour ne plus avoir ce blocage ?

  2. #2
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Ta gestion multithread des sessions est correcte. Par contre, es-tu sur de systématiquement fermer toutes les sessions? Si tu laisse des sessions ouvertes, tu va progressivement consommer ton pool de données jdbc jusqu'à épuisement.

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 9
    Points : 8
    Points
    8
    Par défaut
    Quand tu me dis que "Ta gestion multithread des sessions est correcte", tu parles de la classe utilitaire que j'ai présentée ? Ou la modif que j'ai apportée en créant une session par thread ?
    La classe utilitaire suffit-elle pour le multithreading ?

    En tentant de gérer une session par thread, j'ai créé un singleton qui gère une map avec comme clé l'id du thread et comme valeur la session associée.
    Comme cela, le DAO fait appel à la classe utilitaire, lui demandant la session associée à l'id du thread (Thread.currentThread().getId()).
    Enfin, je ferme la session dans la méthode finalize().

    Cette gestion des session est-elle pérenne ?
    Sinon, dans quelle direction puis-je m'orienter ?

    Avec les recherches que j'ai effectuées, le pool de session est géré habituellement avec un serveur d'application, sauf que j'en ai pas ici. J'ai l'impression de réinventer la roue, mais j'ai besoin de le faire.

  4. #4
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    Citation Envoyé par godjirax Voir le message
    tu parles de la classe utilitaire que j'ai présentée ? Ou la modif que j'ai apportée en créant une session par thread ?
    La classe utilitaire suffit-elle pour le multithreading ?
    De la classe utilitaire que tu as présentée et qui utilise des threadlocal
    En tentant de gérer une session par thread, j'ai créé un singleton qui gère une map avec comme clé l'id du thread et comme valeur la session associée.
    ThreadLocal fait déjà ça pour toi de manière plus performante



    Avec les recherches que j'ai effectuées, le pool de session est géré habituellement avec un serveur d'application, sauf que j'en ai pas ici. J'ai l'impression de réinventer la roue, mais j'ai besoin de le faire.
    Hibernate peux très bien avoir son propre pool. Comme je l'ai dit, assure toi que tu appelle bien systématiquement close(), même en cas d'erreur, d'exception qui remonte -> le mettre dans un bloc finally qui suis l'ouverture. Si tu oublie de fermer des session, ça va s'accumuler jusqu'a soit saturer ton pool, soit sature ta base de donnée (chaque session hibernate a sa propre connexion à la DB)

Discussions similaires

  1. [Hibernate][proxy] Problème exécution requêtes update et remove
    Par amadoulamine1 dans le forum Hibernate
    Réponses: 2
    Dernier message: 08/07/2011, 13h18
  2. Problème de requête (Hibernate sous NetBeans )
    Par meryam123 dans le forum NetBeans
    Réponses: 2
    Dernier message: 02/07/2011, 13h33
  3. Problème de requête sur une vue Hibernate
    Par littlebear dans le forum Hibernate
    Réponses: 16
    Dernier message: 05/01/2009, 15h48
  4. Problème Hibernate exécution d'une requête
    Par blackmisery dans le forum Hibernate
    Réponses: 2
    Dernier message: 13/07/2008, 13h49
  5. problème syntaxe requête select Hibernate
    Par Staron dans le forum Hibernate
    Réponses: 1
    Dernier message: 22/05/2006, 17h54

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