Notions de base - Dépannage Hibernate / Pool de connexions JDBC Problème

Ce qui est de Hibernate responsabilité en ce qui concerne les connexions de base de données qu'il obtient à partir d'une connexion sous-jacente de la piscine. Est-il tester pour voir si une connexion est fermée avant de l'utiliser? et si oui, obtenir une autre connexion de la piscine?

J'ai compris l'erreur et de confirmation, les informations ci-dessous. Toute idée d'où je peux commencer à dépanner ce serait très utile. Et tous les conseils sur le pilote SQL Server paramètres que nous utilisons.

de la Catalina journal:

04-Nov-2010 21:54:52.691 AVERTISSEMENT org.apache.tomcat.jdbc.piscine.ConnectionPool.abandonner la Connexion a été abandonné PooledConnection[ConnectionID:8]:java.lang.Exception 
au org.apache.tomcat.jdbc.piscine.ConnectionPool.getThreadDump(ConnectionPool.java:926) 
au org.apache.tomcat.jdbc.piscine.ConnectionPool.borrowConnection(ConnectionPool.java:681) 
au org.apache.tomcat.jdbc.piscine.ConnectionPool.borrowConnection(ConnectionPool.java:545) 
au org.apache.tomcat.jdbc.piscine.ConnectionPool.getConnection(ConnectionPool.java:166) 
au org.apache.tomcat.jdbc.piscine.DataSourceProxy.getConnection(DataSourceProxy.java:106)

de notre journal d'application:

2010-11-04 21:54:52,705 [tomcat-http--18] AVERTIR util.JDBCExceptionReporter - Erreur SQL: 0, SQLState: 08S01 
2010-11-04 21:54:52,707 [tomcat-http--18] ERREUR util.JDBCExceptionReporter - Socket fermée 
2010-11-04 21:54:52,708 [tomcat-http--18] ERREUR de transaction.JDBCTransaction - JDBC restauration a échoué 
java.sql.SQLException: la Connexion a déjà été fermé. 
au org.apache.tomcat.jdbc.piscine.ProxyConnection.invoke(ProxyConnection.java:112) 
au org.apache.tomcat.jdbc.piscine.JdbcInterceptor.invoke(JdbcInterceptor.java:94) 
au org.apache.tomcat.jdbc.pool.interceptor.AbstractCreateStatementInterceptor.invoke(AbstractCreateStatementInterceptor.java:71) 
au org.apache.tomcat.jdbc.piscine.JdbcInterceptor.invoke(JdbcInterceptor.java:94) 
au org.apache.tomcat.jdbc.piscine.l'intercepteur.ConnectionState.invoke(ConnectionState.java:132) 
à $Proxy38.rollback(Source Inconnue) 
au org.mise en veille prolongée.des transactions.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:217) 
au org.mise en veille prolongée.des transactions.JDBCTransaction.rollback(JDBCTransaction.java:196) 
au org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:676) 
au org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:845) 
au org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:822) 
au org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:412) 
au org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:111) 
au org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) 
au org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)

La configuration:

<Resource defaultAutoCommit="false" defaultReadOnly="false"
        defaultTransactionIsolation="SERIALIZABLE"
        driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
        factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
        fairQueue="false" initialSize="10"
        jdbcInterceptors="ConnectionState;StatementFinalizer"
        jmxEnabled="true" logAbandoned="true" maxActive="100"
        maxIdle="10" maxWait="30000"
        minEvictableIdleTimeMillis="10000" minIdle="10"
        name="com.ourcompany.ap.shoppingcart/datasource"
        password="somePassword" removeAbandoned="true"
        removeAbandonedTimeout="60" testOnBorrow="true"
        testOnReturn="false" testWhileIdle="false"
        timeBetweenEvictionRunsMillis="5000"
        type="javax.sql.DataSource"
        url="jdbc:sqlserver://approd\approd;databaseName=prod"
        useEquals="false" username="AccessPointNet"
        validationInterval="30000" validationQuery="SELECT 1"/>`

OriginalL'auteur BuddyJoe | 2010-11-05

14

Ce qui est de Hibernate responsabilité en ce qui concerne les connexions de base de données qu'il obtient à partir d'une connexion sous-jacente de la piscine.

Pas beaucoup, de le relâcher lorsque le Session se ferme.

T-il un test pour voir si une connexion est fermée avant de l'utiliser? et si oui, obtenir une autre connexion de la piscine?

Non, Hibernate n'est pas le cas, la vérification de la validité de la connexion(s) est de la responsabilité d'un pool de connexion si vous le souhaitez.

J'ai compris l'erreur et de confirmation, les informations ci-dessous. Toute idée d'où je peux commencer à dépanner ce serait très utile.

Quel genre de processus exécutez-vous exactement? Une longue opération? Est-il timeout? Ce qui ne l' Caused by: dire? Sur la trace:
```
2010-11-04 21:54:52,705 [tomcat-http--18] AVERTIR util.JDBCExceptionReporter - Erreur SQL: 0, SQLState: 08S01 
2010-11-04 21:54:52,707 [tomcat-http--18] ERREUR util.JDBCExceptionReporter - Socket fermée 
2010-11-04 21:54:52,708 [tomcat-http--18] ERREUR de transaction.JDBCTransaction - JDBC restauration a échoué java.sql.SQLException: la Connexion a déjà été fermé. 
```
Pouvez-vous reproduire de façon déterministe? Aucun problème de réseau?

Et tous les conseils sur le pilote SQL Server paramètres que nous utilisons.

J'ai ajouté une excellente ressource sur Tomcat et le pool de connexion de configuration ci-dessous. Pas spécifique à SQL Server.

Ressources
- La configuration de jdbc-piscine haut de la simultanéité
OriginalL'auteur Pascal Thivent
17

J'ai eu un problème similaire qui a été résolu par l'augmentation de la removeAbandonedTimeout de la valeur à un nombre plus élevé. Le problème auquel nous sommes confrontés est due à la requête qui a pris plus de temps que le délai mentionné ci-dessus.

Vous plaisantez? Vous êtes juste déplacer le problème le plus long de l'événement dans l'avenir
était juste rencontrant le même problème. Dans mon cas, l'exécution de Jointures EXTERNES créés par Hibernate (due à des entités ayant chargé avec Impatience "OneToMany" dépendances) s'est avéré être prendre beaucoup de temps (plus que mon "removeAbandonedTimeout" réglage (60), et était à l'origine du SQLState: 08S01 erreur. Ressemble à Hibernate est confronté à des difficultés de manipulation des abandonnés les connexions enlever correctement.

OriginalL'auteur Cid
2

Nous avons l'habitude de contourner cela en utilisant dbcp, et de fournir un validationQuery quand definining notre source de données. Ensuite, dbcp permettra de vérifier la facilité d'utilisation de connexions regroupées par l'émission de cette requête (et de manière transparente recréer la connexion, si elle n'a plus de travail), avant de les restituer à la demande.

Découvrez
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
pour plus de détails.

OriginalL'auteur meriton
2

Je suis actuellement en utilisant liquibase(v1.9) dans mon projet, et lors de la révision de l'exécuter sur un vide schéma, il prend toujours plus de temps de 60 secondes, qui résultats dans le fil marqué abandonnée je ne suis pas heureux avec l'augmentation de la removeAbandonedTimeout valeur, mais c'est la seule solution que j'ai pu trouver pour éviter ce problème; cependant, d'après le schéma initial de la population est complet, c'est rarement un problème donc j'ai défini la valeur de retour de 60 secondes.

OriginalL'auteur mjj1409
1

J'ai travaillé sur un problème dans le passé, nous n'avons pas de retour des connexions de retour à la piscine correctement. Ainsi, lorsqu'une connexion a été utilisée et n'est pas retourné, en faisant une base de données d'appel lorsqu'il a été timing serait de lever une exception.

Nous avons été en mesure de reproduire le problème en faisant un appel à la base de données, attendu 8 heures (postgres' par défaut time out) et essayé de faire un appel à la base de données à nouveau. Il jeter la même exception à chaque fois. Notre solution a été de repenser (ou, mieux encore, ajouter) une connexion stratégie de gestion.

Donc, pour résumer, vous êtes réellement le retour de vos connexions à la piscine par la fermeture de la Session?

J'ai aussi été confronté à ce problème quand j'essaie d'insérer plusieurs enregistrements à la fois (travail de téléchargement le fichier se compose de 1,60, 000 dossiers). J'ai obtenu l'erreur exactement après 5 minutes. a été en mesure de reproduire de nombreuses fois tout le temps, il jeté l'erreur au bout de 5 minutes. certains ont-ils un pls m'aider?

OriginalL'auteur Jeremy

J'ai eu la solution par l'exception ci-dessus.
Il suffit de fermer l'instance de session de l'usine ainsi lors de la fermeture de la session .

Regardez le Code ci-dessous:

public class HibernateUtil {
    private static final SessionFactory sessionFactory = buildSessionFactory();

    private static SessionFactory buildSessionFactory() {
        try {
            //Create the SessionFactory from hibernate.cfg.xml
            return new Configuration().configure("hibernate.cfg.xml").buildSessionFactory();
        }
        catch (Throwable ex) {
            ex.printStackTrace();
            //Make sure you log the exception, as it might be swallowed
            System.err.println("Initial SessionFactory creation failed." + ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static SessionFactory getSessionfactory() {
        return sessionFactory;
    }

    public static Session getSession() {
        Session session=sessionFactory.openSession();
        session.getTransaction().begin();
        return session;
    }
    public static void closeSession(Session session) {
        if(session!=null )
        {
            if(session.getTransaction().isActive())
            {
                session.getTransaction().commit();
            }
                session.close();
                getSessionfactory().close();
        }
    }
}

il suffit d'appeler la méthode HibernateUtil.closeSession(). Cela permettra de résoudre le problème.

Je ne pense pas que ce soit recommandé: stackoverflow.com/questions/33236407/...

OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.

Ressources