Conflit du pool Hibernate avec Mysql?

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/08/2011, 20h19
SaladinDev

Pour cerné encore le problème j'ajoute ceci:
Lorsque c'est bloqué depuis l'application déployée sur le net ,si j'accède à la même base de données mais avec une application déployée sur mon ordinateur ,je n'ai aucun problème de connexion.
Aussi si j'ouvre un outil de connexion de base de données(sql manger), je n'ai aucun soucis pour exécuté des requête.
Donc ce n'est pas un problème de transaction mal fermé.
10/08/2011, 21h14
tchize_

Utilisez le pool de votre conteneur via jndi plutot que celui de c3p0, la plupart des conteneur permettent de configurer une commande sql lors du checkout depuis le pool, ce qui permet de garantir que toutes les connexions sont ok.
11/08/2011, 08h46
JeitEmgie
Citation:

Envoyé par tchize_

Utilisez le pool de votre conteneur via jndi plutot que celui de c3p0, la plupart des conteneur permettent de configurer une commande sql lors du checkout depuis le pool, ce qui permet de garantir que toutes les connexions sont ok.

c'est le
Code:

1 2 destroy-method="close"
que l'on peut mettre dans le bean dataSource :
Code:

1 2 3 4 <bean id="dataSource" … destroy-method="close"> … </bean>
quand on utilise un application context…
la question est de savoir où le mettre quand on utilise

Code:

<hibernate-configuration>

…
ou
alors utiliser la technique décrite sur le site de c3p0 dans le paragraphe "Cleaning up after c3p0 PooledDataSources"
11/08/2011, 10h08
tchize_

non le destroy mùethod de spring n'a rien à voir, ca concerne la méthode a appeler pour détruire le pool. Je parle ici de choses du genre

Code:

<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>

qu'on peux mettre dans jboss ou

Code:

<Resource type="javax.sql.DataSource" validationQuery="select 1 from dual" validationQueryTimeout="5" ...../>

dans tomcat

J'ai beau lire la doc de c3p0, visiblement ce pool là n'a pas cette possibilité.

Citation:

Envoyé par tchize_

non le destroy mùethod de spring n'a rien à voir, ca concerne la méthode a appeler pour détruire le pool. Je parle ici de choses du genre

Code:

<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>

qu'on peux mettre dans jboss ou

Code:

<Resource type="javax.sql.DataSource" validationQuery="select 1 from dual" validationQueryTimeout="5" ...../>

dans tomcat

J'ai beau lire la doc de c3p0, visiblement ce pool là n'a pas cette possibilité.

Code:

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
<bean id=YOUR_DATASOURCE_BEAN_NAME"
          destroy-method="close"
          class="com.mchange.v2.c3p0.ComboPooledDataSource">
        <property name="jdbcUrl"
                  value="${hibernate.connection.url}"/>
        <property name="driverClass"
                  value="${hibernate.connection.driver_class}"/>
        <property name="user"
                  value="${hibernate.connection.username}"/>
        <property name="password"
                  value="${hibernate.connection.password}"/>
        <property name="maxPoolSize"
                  value="${datasource.c3p0.maxPoolSize}"/>
        <property name="preferredTestQuery"
                  value="${datasource.c3p0.preferredTestQuery}"/>
        <property name="idleConnectionTestPeriod"
                  value="${datasource.c3p0.idleConnectionTestPeriod}"/>
        <property name="testConnectionOnCheckin"
                  value="${datasource.c3p0.testConnectionOnCheckin}"/>
        <property name="unreturnedConnectionTimeout"
                  value="${datasource.c3p0.unreturnedConnectionTimeout}"/>
        <property name="debugUnreturnedConnectionStackTraces"
                  value="${datasource.c3p0.debugUnreturnedConnectionStackTraces}"/>
</bean>

avec

Code:

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
…
hibernate.connection.url=jdbc:mysql://YOUR_IP:YOUR_PORT/YOUR_DBNAME?characterEncoding=YOUR_ENCODING&autoReconnect=true&useServerPrepStmts=YOUR_NEEDS
…
# Defines the query that will be executed for all connection tests,
# if the default ConnectionTester (or some other implementation of
# QueryConnectionTester, or better yet FullQueryConnectionTester) is being used.
# Defining a preferredTestQuery that will execute quickly in your database may
# dramatically speed up Connection tests. (If no preferredTestQuery is set, the
# default ConnectionTester executes a getTables() call on the Connection's
# DatabaseMetaData. Depending on your database, this may execute more slowly
# than a "normal" database query.)
# NOTE: The table against which your preferredTestQuery will be run must exist
# in the database schema prior to your initialization of your DataSource.
# If your application defines its own schema, try automaticTestTable instead.

datasource.c3p0.preferredTestQuery=select 1 from dual

# If this is a number greater than 0, c3p0 will test all idle, pooled but
# unchecked-out connections, every this number of seconds.

datasource.c3p0.idleConnectionTestPeriod=300

# If true, an operation will be performed asynchronously at every connection
# checkin to verify that the connection is valid. Use in combination with
# idleConnectionTestPeriod for quite reliable, always asynchronous Connection
# testing. Also, setting an automaticTestTable or preferredTestQuery will
# usually speed up all connection tests.

datasource.c3p0.testConnectionOnCheckin=true

# Seconds. If set, if an application checks out but then fails to check-in
# [i.e. close()] a Connection within the specified period of time, the pool
# will unceremoniously destroy() the Connection. This permits applications with
# occasional Connection leaks to survive, rather than eventually exhausting the
# Connection pool. And that's a shame. Zero means no timeout, applications are
# expected to close() their own Connections. Obviously, if a non-zero value is
# set, it should be to a value longer than any Connection should reasonably be
# checked-out. Otherwise, the pool will occasionally kill Connections in active
# use, which is bad. This is basically a bad idea, but it's a commonly
# requested feature. Fix your $%!@% applications so they don't leak Connections!
# Use this temporarily in combination with debugUnreturnedConnectionStackTraces
# to figure out where Connections are being checked-out that don't make it
# back into the pool!

datasource.c3p0.unreturnedConnectionTimeout=0

# If true, and if unreturnedConnectionTimeout is set to a positive value, then
# the pool will capture the stack trace (via an Exception) of all Connection
# checkouts, and the stack traces will be printed when unreturned checked-out
# Connections timeout. This is intended to debug applications with Connection
# leaks, that is applications that occasionally fail to return Connections,
# leading to pool growth, and eventually exhaustion (when the pool hits
# maxPoolSize with all Connections checked-out and lost). This parameter should
# only be set while debugging, as capturing the stack trace will slow down
# every Connection check-out.

datasource.c3p0.debugUnreturnedConnectionStackTraces=false 
…

dans le fichier de properties définissant les paramètres

11/08/2011, 21h17
SaladinDev

toutes ces réponses sont un peu difficile à comprendre,je veux comprendre se qui se passe théoriquement ,le cycle de vie d'une session hibernation, et pourquoi ça finie par bloqué au bout d'un moment.
11/08/2011, 23h24
tchize_
une session:
1. On prend un connexion dans le pool
2. On démarre un transaction
3. on deshydrate quelques objets, on les travaille, on les sauve
4. on commit
5. on rend la connexion au pool
Dans ton cas, pendant que la connexion est dans le pool elle périclite (par exemple parce que le serveur SQL l'a abandonnée faute d'inactivité, parce que le serveur SQL a redémarré, parce que le serveur SQL est buggé, etc), et quand on la récupère au point 1 elle est dans un sale état. D'ou l'intéret de demander au pool de la vérifier avant de te la donner, via une requete de test qui doit réussir à tous les coup.

La vérification de l'état de la connexion c'est justement le rôle des balises :
Code:

1 2 3 4 5 6 7 8 9 <property name="c3p0.acquire_increment">2</property> <property name="c3p0.idle_test_period">3000</property> <property name="c3p0.timeout">1800</property> <property name="c3p0.max_size">25</property> <property name="c3p0.min_size" >3</property> <property name="c3p0.max_statement">0</property> <property name="c3p0.preferredTestQuery">select 1;</property> <property name="c3p0.validate">true</property>
donc soit c'est autre chose ou alors hibernate n'a pas pris en compte ces informations.

Voir 40 message(s) de cette discussion en une page