Revision a375171e
Added by Andreas Kohlbecker almost 9 years ago
src/main/resources/c3p0.properties | ||
---|---|---|
1 | 1 |
# |
2 |
# The CDM-Server instantiates the 3cp0 connection pools on behalf of the cdm-remote-webapp instances and passes |
|
3 |
# the the connection pool per JNDI to the cdm-webapp instances. Thus we need to repeat the configuration as |
|
4 |
# defined in cdmlib-persistence\src\main\resources\c3p0-config.xml |
|
2 |
# The CDM-Server instantiates the 3cp0 connection pools on behalf of the cdm-remote-webapp |
|
3 |
# instances and passes the the connection pool per JNDI to the cdm-webapp instances. Thus |
|
4 |
# we need to repeat the configuration as defined in |
|
5 |
# cdmlib-persistence\src\main\resources\c3p0-config.xml |
|
5 | 6 |
# |
6 |
|
|
7 |
## idleConnectionTestPeriod: |
|
8 |
# if this is a number greater than 0, c3p0 |
|
9 |
# will test all idle, pooled but unchecked-out connections, every this |
|
10 |
# number of seconds |
|
11 |
#c3p0.idleConnectionTestPeriod = 60 |
|
12 |
|
|
13 | 7 |
# For some applications, high performance is more important than the risk of an |
14 | 8 |
# occasional database exception. In its default configuration, c3p0 does no |
15 | 9 |
# Connection testing at all. Setting a fairly long idleConnectionTestPeriod, and |
16 | 10 |
# not testing on checkout and check-in at all is an excellent, high-performance |
17 |
# approach. |
|
11 |
# approach. (from official doc)
|
|
18 | 12 |
# |
19 | 13 |
|
20 |
c3p0.idleConnectionTestPeriod = 120 |
|
14 |
## idleConnectionTestPeriod: |
|
15 |
# if this is a number greater than 0, c3p0 |
|
16 |
# will test all idle, pooled but unchecked-out connections, every this |
|
17 |
# number of seconds. |
|
18 |
# If database restarts will be rare so quick recovery is not an issue, |
|
19 |
# consider reducing the frequency of tests by idleConnectionTestPeriod |
|
20 |
# to, say, 300, and see whether clients are troubled by stale or broken |
|
21 |
# Connections. If not, stick with 300, or try an even bigger number. |
|
22 |
# |
|
23 |
c3p0.idleConnectionTestPeriod = 600 |
|
24 |
|
|
21 | 25 |
c3p0.testConnectionOnCheckout = false |
22 | 26 |
c3p0.testConnectionOnCheckin = false |
23 |
c3p0.maxConnectionAge = 600 |
|
24 |
c3p0.maxIdleTime = 300 |
|
25 |
c3p0.maxIdleTimeExcessConnections = 200 |
|
27 |
|
|
26 | 28 |
c3p0.minPoolSize = 1 |
29 |
####### timeout parameters |
|
30 |
# |
|
31 |
# Some general advice about all of these timeout parameters: Slow down! The point |
|
32 |
# of Connection pooling is to bear the cost of acquiring a Connection only once, |
|
33 |
# and then to reuse the Connection many, many times. Most databases support Connections |
|
34 |
# that remain open for hours at a time. There's no need to churn through all your |
|
35 |
# Connections every few seconds or minutes. Setting maxConnectionAge or maxIdleTime |
|
36 |
# to 1800 (30 minutes) is quite aggressive. For most databases, several hours may |
|
37 |
# be more appropriate. You can ensure the reliability of your Connections by testing |
|
38 |
# them, rather than by tossing them. (see Configuring Connection Testing.) The only |
|
39 |
# one of these parameters that should generally be set to a few minutes or less is |
|
40 |
# maxIdleTimeExcessConnections. (from official doc) |
|
41 |
|
|
42 |
## maxConnectionAge |
|
43 |
# Seconds, effectively a time to live. A Connection older than |
|
44 |
# maxConnectionAge will be destroyed and purged from the pool. |
|
45 |
# |
|
46 |
# turned off as suggested above |
|
47 |
#c3p0.maxConnectionAge = 600 |
|
48 |
|
|
49 |
# maxIdleTime 10800 = 3 hours |
|
50 |
c3p0.maxIdleTime = 10800 |
|
51 |
|
|
52 |
c3p0.maxIdleTimeExcessConnections = 300 |
|
27 | 53 |
|
28 | 54 |
## automatichoweverTestTable: |
29 | 55 |
# If provided, c3p0 will create an |
... | ... | |
36 | 62 |
c3p0.automaticTestTable = _c3p0ConnectionTest |
37 | 63 |
|
38 | 64 |
# if you do not want c3p0 to register MBeans with your JMX environment, you can suppress JMX support entirely |
39 |
# for some reason this is required for the cdm-server:
|
|
65 |
# The ManagementCoordinator was causing problems in the past but seem to be ok now.
|
|
40 | 66 |
#c3p0.management.ManagementCoordinator=com.mchange.v2.c3p0.management.NullManagementCoordinator |
Also available in: Unified diff
applying more config changes according to recommendations in the official c3p0 doc