47 votes

Quels sont les paramètres C3P0 requis pour la mise en veille prolongée afin d'éviter les blocages

J'utilise Hibernate avec MySQL 5.1.30.

J'ai des bibliothèques suivantes:

  • c3p0-0.0.1.2.jar
  • mysql-connector-java-5.0.3-bin.jar
  • hibernate3.jar

J'utilise un hibernate.cfg.xml pour la configuration:

<!DOCTYPE hibernate-configuration PUBLIC
    "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
    "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
    <session-factory>
        <!-- Database connection settings -->
        <property name="connection.driver_class">org.gjt.mm.mysql.Driver</property> 

        <property name="connection.url">jdbc:mysql://localhost/fooDatatbase</property>
    <property name="connection.username">foo</property>
    <property name="connection.password">foo123</property>

        <!-- Use the C3P0 connection pool provider -->
    <property name="hibernate.c3p0.min_size">5</property>
    <property name="hibernate.c3p0.max_size">20</property>
    <property name="hibernate.c3p0.timeout">300</property>
    <property name="hibernate.c3p0.max_statements">50</property>
    <property name="hibernate.c3p0.idle_test_periods">3000</property>       

        <!-- SQL dialect -->
        <property name="dialect">org.hibernate.dialect.MySQLDialect</property>

        <!-- Enable Hibernate's automatic session context management -->
        <property name="current_session_context_class">thread</property>

        <!-- Disable the second-level cache  -->
        <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

        <!-- Echo all executed SQL to stdout -->
        <property name="show_sql">true</property>

        <mapping resource="databaselayer/mail/Mail.hbm.xml"/>
        <mapping resource="databaselayer/courses/Course.hbm.xml"/>
        <mapping resource="databaselayer/price/Price.hbm.xml"/>        
        <mapping resource="databaselayer/contact/Contact.hbm.xml"/>
        <mapping resource="databaselayer/artists/Musician.hbm.xml"/>
        <mapping resource="databaselayer/concerts/Concert.hbm.xml"/>     
        <mapping resource="databaselayer/welcome/Welcome.hbm.xml"/>
        <mapping resource="databaselayer/information/Information.hbm.xml"/>                             
    </session-factory>
</hibernate-configuration>

Dans le JAVA persistance avec hibernate livre, c3p0 les options de configuration sont expliquées:

  • mise en veille prolongée.c3p0.min_size C'est le nombre minimum de connexions JDBC que C3P0 tient prêt à tout moment
  • mise en veille prolongée.c3p0.max_size C'est le nombre maximal de connexions dans le pool. Une exception est levée lors de l'exécution si ce numéro est épuisé.
  • mise en veille prolongée.c3p0.délai d'attente Vous spécifiez le délai d'attente (dans ce cas, à 300 secondes) au bout duquel la connexion inactive est retiré de la piscine).
  • mise en veille prolongée.c3p0.max_statements Nombre Maximal d'instructions qui seront mis en cache. La mise en cache des requêtes préparées est essentiel pour de meilleures performances avec la mise en veille prolongée.
  • mise en veille prolongée.c3p0.idle_test_periods C'est le inactive temps en secondes avant que la connexion est automatiquement validée.

J'utilise Java 1.5.0_09 et tomcat 6.0. J'ai trois applications déployées dans tomcat. Chacun d'entre eux utilise hibernate avec un fichier de configuration presque l'équivalent de l'exemple ci-dessus (seulement de nom d'utilisateur, de base, mot de passe et la cartographie resoruces changement).

Malheureusement, avec les paramètres ci-dessus, après quelques heures de fonctionnement-je obtenir une méchante erreurs de Blocage de l'extrémité de tuer tomcat.

Jan 22, 2009 3:29:07 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run
WARNING: com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@2437d -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Jan 22, 2009 3:29:07 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run
WARNING: com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@1dc5cb7 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Jan 22, 2009 3:29:07 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run
WARNING: com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@9cd2ef -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Jan 22, 2009 3:29:07 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run
WARNING: com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@4af355 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Jan 22, 2009 3:29:07 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run
WARNING: com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@1275fcb -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Jan 22, 2009 3:29:35 PM com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector run

Cela semble être une erreur plusieurs personnes déjà obtenu. J'ai changé mes paramètres d'essayer de suivre la solution de contournement décrite icihttp://forum.hibernate.org/viewtopic.php?p=2386237 pour:

<property name="hibernate.c3p0.acquire_increment">1</property>
<property name="hibernate.c3p0.min_size">0</property>
<property name="hibernate.c3p0.max_size">48</property>
<property name="hibernate.c3p0.timeout">0</property>
<property name="hibernate.c3p0.max_statements">0</property>

Avec les nouveaux paramètres, je ne reçois pas les Blocages, mais j'obtiens:

WARNING: SQL Error: 0, SQLState: 08S01
Jan 24, 2009 5:53:37 AM org.hibernate.util.JDBCExceptionReporter logExceptions
SEVERE: Communications link failure due to underlying exception: 

** BEGIN NESTED EXCEPTION ** 

java.io.EOFException

STACKTRACE:

java.io.EOFException
    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1913)

Personne ne sait ce que je fais de mal, et comment je peux le programme d'installation de c3p0 correctement?

49voto

Thomas Weber Points 478

En fait, c'est probablement trop tard, mais le problème est assez simple: hibernate.c3p0.idle_test_periods ne doit pas être supérieure à hibernate.c3p0.timeout ou connexions fermé par la base de données ne sera pas détecté correctement.

En outre, la détection de blocage mises en garde ressembler à une partie de votre code n'est pas bien de retourner les connexions à la piscine (c'est à dire de la session.close())

Le MysqlIO des exceptions se produisent lorsque votre application tourne au ralenti et MySQL ferme la connexion sur le serveur. Maintenant, si C3P0 ne fait pas de bien vérifier si une connexion est encore connecté, vous obtenez le EOFExceptions.

J'espère que ce pourrait être utile.

9voto

Varun Mehta Points 1347

Il n'y a pas de réponse définitive à cette question, car il varie d'une application à l'autre en fonction de l'utilisation et modèle de charge.

Premier point est de consulter le lien https://www.hibernate.org/214.htmlpuisqu'il semble que vous avez fait cela et aller de l'avant. voici quelques conseils;

  • numHelperThreads : Helper threads qui ne détiennent pas soutenu les verrous. La diffusion de ces opérations sur plusieurs threads
  • maxStatements : La taille de c3p0 mondial de PreparedStatement cache.
  • maxStatementsPerConnection : Le nombre de PreparedStatements c3p0 en cache pour un seul pool de Connexion.
  • maxAdministrativeTaskTime : Paramètre qui force un appel à la thread de tâche d'interruption du (), méthode si une tâche dépasse un temps limite

Trois premiers paramètre peut améliorer ou de réduire le rendement en fonction de la valeur définie où, comme quatrième paramètre peut interrompre le fil après la limite de jeu et de donner un changement de courir pour les autres fil.

Les valeurs approximatives

  • numHelperThreads = 6
  • maxStatements =100
  • maxStatementsPerConnection = 12
  • maxAdministrativeTaskTime = besoin de suffisamment de temps, de sorte que la lourdeur de la requête peut s'exécuter sur la production

maxStatements et maxStatementsPerConnection doit être testé pour les quelques mois à quelques détachement point mort verrouillage en raison de ces paramètres.

Se référant également à ces liens sera utile;

3voto

user2935659 Points 16

Les hibernate.c3p0.idle_test_periods doivent être inférieurs à h * ibernate.c3p0.timeout * car le premier n'est qu'une valeur de temps où hibernate vérifie les connexions inactives et tente de le fermer.

En attendant, la seconde est combien de temps une connexion doit être éjectée.

Si la valeur idle_test_periods est supérieure au paramètre timeout à celui d'hibernate, recherchez tout ce qui est null ou n'existe pas dans le système. Au moins j'ai compris de cette façon.

1voto

Trenton Points 2315

C'est une ancienne version de Connector / J. Pour vous assurer que vous ne combattez pas un bogue connu et résolu, commencez par vous procurer le plus récent (5.0.8):

http://dev.mysql.com/downloads/connector/j/5.0.html

Ce EOFException de MysqlIO est un peu suspect. Sous une utilisation normale / non boguée, vous ne devriez jamais obtenir d'erreurs de cette couche.

0voto

duffymo Points 188155

Les trois applications partagent-elles le même pool de connexions ou chacune at-elle son propre? Je recommanderais ce dernier.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X